Agregar clave pública a ~/.ssh/autorized_keys no me registra automáticamente

https://stackoverflow.com/questions/6377009

28-10-2019
|

Pregunta

Agregué la clave SSH pública al archivo autorizado_keys. ssh localhost Debería iniciar sesión sin pedir la contraseña.

Hice eso e intenté escribir ssh localhost, pero todavía me pide que escriba la contraseña. ¿Hay alguna otra configuración que tenga que pasar para que funcione?

He seguido la instrucción para cambiar los permisos:

A continuación se muestra el resultado si lo hago ssh -v localhost

debug1: Reading configuration data /home/john/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to localhost [127.0.0.1] port 22.
debug1: Connection established.
debug1: identity file /home/john/.ssh/identity type 1
debug1: identity file /home/john/.ssh/id_rsa type -1
debug1: identity file /home/john/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.7p1 Debian-8ubuntu3
debug1: match: OpenSSH_4.7p1 Debian-8ubuntu3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.7p1 Debian-8ubuntu3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'localhost' is known and matches the RSA host key.
debug1: Found key in /home/john/.ssh/known_hosts:12
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: /home/john/.ssh/identity
debug1: Server accepts key: pkalg ssh-rsa blen 149
debug1: PEM_read_PrivateKey failed
debug1: read PEM private key done: type <unknown>

Luego pide PasSphase después del registro anterior. ¿Por qué no me registra sin contraseña?

Solución

Necesita verificar los permisos del authorized_keys Archivo y las carpetas de carpetas / principales en las que se encuentra.

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Para más información, ver esta página.

También es posible que deba cambiar/verificar los permisos de su directorio de inicio para eliminar el acceso de escritura para el grupo y otros.

chmod go-w ~

Otros consejos

Selinux también puede hacer que los Keys autorizados no funcionen. Especialmente para la raíz en CentOS 6 y 7. Sin embargo, no hay necesidad de deshabilitarla. Una vez que haya verificado que sus permisos sean correctos, puede solucionar esto así:

chmod 700 /root/.ssh
chmod 600 /root/.ssh/authorized_keys
restorecon -R -v /root/.ssh

ajuste SSH Authorized_Keys Parece ser simple, pero oculta algunas trampas que estoy tratando de imaginar

-servidor-

en /etc/ssh/sshd_config establecer passwordAuthentication yes para que el servidor acepte temporalmente la autenticación de contraseña

-- CLIENTE --

considerar cygwin Como Linux Emulación e Install & Run OpenSsh

1. Generar claves privadas y públicas (lado del cliente)# ssh-keygen

aquí presionando solo ingreses obtienes DEFECTO2 archivos "ID_RSA" y "id_rsa.pub" en ~/.ssh/ Pero si le das un name_for_the_key Los archivos generados se guardan en su pwd

2. colocar el you_key.pub a la máquina de destino ssh-copy-id user_name@host_name

Si no creó la clave predeterminada, este es el primer paso para salir mal ... debería usar

ssh-copy-id -i path/to/key_name.pub user_name@host_name

3. Inicio sesión ssh user_name@host_name funcionará solo para id_rsa predeterminado, así que aquí hay una segunda trampa para que necesite ssh -i path/to/key_name user@host

(usar ssh -v ... opción para ver lo que está pasando)

Si El servidor todavía pide contraseña Entonces le diste a Smth. a Ingrese la frase de pass: Cuando has creado claves (así que es normal)

Si SSH no escucha el puerto predeterminado 22 debe usar ssh -p port_nr

-servidor -----

4. modificar /etc/ssh/sshd_config tener

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile  %h/.ssh/authorized_keys

(Incomente si el caso)

Esto le dice a SSH que acepte Authorized_Keys y busque en el directorio de inicio del usuario para el archivo Key_Name Sting escrito en el archivo .SSH/Authorized_Keys

5 Establecer permisos en la máquina de destino

chmod 755 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

También apagar la autenticación de pase

passwordAuthentication no

Para cerrar la puerta a todos los intentos de ssh root/admin /....@ su_domain

6 Asegúrese de que la propiedad y la propiedad grupal de todos los directorios de origen no raíz sean apropiados.

chown -R ~ usernamehere
chgrp -R ~/.ssh/ user

===============================================

7. Considere el excelente http://www.fail2ban.org

8. extratúnel ssh Para acceder a un mysql (bind = 127.0.0.1) sever

También asegúrese de que otros directorio de inicio no sea escrito por otros

chmod g-w,o-w /home/USERNAME

La respuesta es robada de aquí

El desesperado también puede asegurarse de que no tengan nuevas líneas adicionales en el archivo Authorized_Keys debido a la copia de ID_RSA.Pub Text fuera de un terminal confundido.

La lista de una clave pública en .ssh/autorized_keys es necesaria pero no suficiente para que SSHD (servidor) la acepte. Si su clave privada está protegida con frase, deberá darle a SSH (cliente) la frase de pases cada vez. O puede usar SSH-agent, o un equivalente de gnomo.

Su rastreo actualizado es consistente con una clave privada protegida por frase de pases. Ver ssh-agent, o ssh-keygen -p.

Tenga cuidado de que Selinux también puede activar este error, incluso si todos los permisos parecen estar bien. Deshabilitarlo hizo el truco para mí (inserte descargas de responsabilidad habituales para deshabilitarlo).

El usuario es su nombre de usuario

mkdir -p /home/user/.ssh
ssh-keygen -t rsa
touch /home/user/.ssh/authorized_keys
touch /home/user/.ssh/known_hosts
chown -R user:user /home/user/.ssh
chmod 700 /home/user/.ssh
chmod 600 /home/user/.ssh/id*
chmod 644 /home/user/.ssh/id*.pub
chmod 644 /home/user/.ssh/authorized_keys
chmod 644 /home/user/.ssh/known_hosts

Lo que me hizo el truco finalmente fue asegurarse de que el propietario/grupo no eran root sino usuario:

chown -R ~/.ssh/ user
chgrp -R ~/.ssh/ user

Escribir comando:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Después de hacer esto, asegúrese de que su director sea así:

drwx------ 2 lab lab 4.0K Mar 13 08:33 .
drwx------ 8 lab lab 4.0K Mar 13 08:07 ..
-rw------- 1 lab lab  436 Mar 13 08:33 authorized_keys
-rw------- 1 lab lab 1.7K Mar 13 07:35 id_rsa
-rw-r--r-- 1 lab lab  413 Mar 13 07:35 id_rsa.pub

Prueba "SSH-Add" que funcionó para mí.

Otro consejo para recordar. Desde que V7.0 se abre desactivaciones Las claves DSS/DSA SSH por defecto debido a su debilidad heredada. Entonces, si tiene OpenSSH v7.0+, asegúrese de que su clave no sea ssh-dss.

Si está atrapado con las teclas DSA, puede volver a habilitar el soporte localmente actualizando su sshd_config y ~/.ssh/config archivos con líneas como así: PubkeyAcceptedKeyTypes=+ssh-dss

En mi caso necesitaba poner mi authorized_keys presentar en .openssh.

Esta ubicación se especifica en /etc/ssh/sshd_config bajo la opción AuthorizedKeysFile %h/.ssh/authorized_keys.

Asegúrese de que el usuario de destino tenga una contraseña establecida. Correr passwd username para establecer uno. Esto fue necesario para mí incluso si el inicio de sesión de SSH fue deshabilitado.

Esto resuelve mi problema

ssh-agent bash

ssh-add

Otro problema que tienes que cuidar. Si su archivo generado no es predeterminadoid_rsa y id_rsa.pub

Debe crear el archivo .ssh/config y definir manualmente qué archivo de identificación usará con la conexión.

El ejemplo está aquí:

host remote_host_name
hostname 172.xx.xx.xx
user my_user
IdentityFile /home/my_user/.ssh/my_user_custom.pub

Emití sudo chmod 700 ~/.ssh y chmod 600 ~/.ssh/authorized_keys y chmod go-w $HOME $HOME/.ssh Desde arriba y solucionó mi problema en una caja CENTOS7 que había estropeado los permisos mientras intentaba que las acciones de Samba funcionen. Gracias

Parece un problema de permiso. Por lo general, ocurre si el permiso de algún archivo/directorio no está configurado correctamente. En la mayoría de los casos son ~/.ssh y ~/.ssh/*. En mi caso son /home/xxx.

Puede cambiar el nivel de registro de SSHD modificando /etc/ssh/sshd_config(búsqueda LogLevel, establecerlo en DEBUG), luego verifique la salida en /var/log/auth.log para ver lo que pasó exactamente.

Mi problema era un File autorizado modificado, cuando la automatización para poblar/etc/ssh/autorized_keys aún no se había ejecutado.

$sudo grep AuthorizedKeysFile /etc/ssh/sshd_config
#AuthorizedKeysFile .ssh/authorized_keys
AuthorizedKeysFile  /etc/ssh/authorized_keys/%u

Solo mira /var/log/auth.log sobre el servidor. Establecer verbosidad adicional con -vv En el lado del cliente no ayudará, porque es poco probable que el servidor ofrezca demasiada información a un posible atacante.

Asegúrese de haber copiado toda la clave pública para authorized_keys; la ssh rsa El prefijo es necesario para que la clave funcione.

Debe verificar las propiedades de los archivos. Para asignar el uso de la propiedad requerida:

$ chmod 600 ~/.ssh/sshKey
$ chmod 644 ~/.ssh/sshKey.pub

En esa nota, asegúrese de que la configuración SSHD tenga -;

PermitRootLogin without-password

Establezca como el anterior, luego reinicie SSHD (/etc/init.d/sshd reiniciar)

¡Inicie sesión y intente iniciar sesión nuevamente!

predeterminado, creo que es -;

PermitRootLogin no

En mi caso, se debe a que el grupo del usuario no está configurado en los grupos de configuración del archivo de configuración/etc/ssh/sshd_config. Después de agregarlo, todo funciona bien.

Tengo el directorio de inicio en una ubicación no estándar y en sshd registros tengo esta línea:

Could not open authorized keys '/data/home/user1/.ssh/authorized_keys': Permission denied

Incluso si todos los permisos estuvieran bien (vea las otras respuestas).

He encontrado una solución aquí: http://arstechnica.com/civis/viewtopic.php?p=25813191&sid=0876f069ec2aa5fdcd691a2e2e7242c2#p25813191

En mi caso particular:

Se agregó una nueva línea en /etc/selinux/targeted/contexts/files/file_contexts.homedirs:
- Esta es la línea original para directorios regulares del hogar:
  
  /home/[^/]*/\.ssh(/.*)? unconfined_u:object_r:ssh_home_t:s0
- Esta es mi nueva línea:
  
  /data/home/[^/]*/\.ssh(/.*)? unconfined_u:object_r:ssh_home_t:s0
seguido de un restorecon -r /data/ y un sshd reiniciar

Tuve este problema y ninguna de las otras respuestas lo resolvió, aunque por supuesto las otras respuestas son correcto.

En mi caso, resultó que el /root directorio en sí (no por ejemplo /root/.ssh) tenía los permisos incorrectos. Lo necesitaba:

chown root.root /root
chmod 700 /root

Por supuesto, esos permisos deberían ser algo así (tal vez chmod 770) sin importar. Sin embargo, se evita específicamente sshd de trabajar, aunque /root/.ssh y /root/.ssh/authorized_keys Ambos tenían permisos y propietarios correctos.

Mirar /var/log/auth.log en el servidor para sshd Errores de autenticación.

Si todo lo demás falla, entonces ejecute el sshd servidor en modo de depuración:

sudo /usr/sbin/sshd -ddd -p 2200

Luego conéctese desde el cliente:

ssh user@host -p 2200

En mi caso, encontré la sección de error al final:

    debug1: userauth_pubkey: test whether pkalg/pkblob are acceptable for RSA SHA256:6bL+waAtghY5BOaY9i+pIX9wHJHvY4r/mOh2YaL9RvQ [preauth]
==> debug2: userauth_pubkey: disabled because of invalid user [preauth]
    debug2: userauth_pubkey: authenticated 0 pkalg ssh-rsa [preauth]
    debug3: userauth_finish: failure partial=0 next methods="publickey,password" [preauth]
    debug3: send packet: type 51 [preauth]
    debug3: receive packet: type 50 [preauth]

Con esta información me di cuenta de que mi sshd_config estaba restringiendo los inicios de sesión a los miembros del ssh grupo. El siguiente comando corrigió este error de permiso:

sudo usermod -a -G ssh NEW_USER

Tuve este problema cuando agregué el grupo del usuario de inicio de sesión a otro usuario. Digamos que hay un usuario de SSH-Login llamado UserA y un usuario de usuario no SSH-login. UserA tiene el grupo UserA también. Modifiqué UserB para tener el grupo de usuarios también. El conducto al comportamiento descrito, de modo que UserA no pudo iniciar sesión sin un mensaje. Después de eliminar el grupo userA de userb, el inicio de sesión sin solicitud funcionó nuevamente.

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow