¿Por qué sigo recibiendo una solicitud de contraseña con ssh con autenticación de clave pública?

Estoy trabajando desde la URL que encontré aquí:

http://web.archive.org/web/20160404025901/http://jaybyjayfresh.com/2009/02/04/logging-in-without-a-password-certificates-ssh/

Mi cliente ssh es Ubuntu 64 bit 11.10 de escritorio y mi servidor es Centos 6.2 64 bit. He seguido las instrucciones. Todavía recibo un mensaje de contraseña en ssh.

No estoy seguro de qué hacer a continuación.

Asegúrese de que los permisos en el ~/.sshdirectorio y su contenido sean correctos. Cuando configuré por primera vez la autenticación de mi clave ssh, no tenía la ~/.sshcarpeta configurada correctamente y me gritó.

• Su directorio de inicio ~, su ~/.sshdirectorio y el ~/.ssh/authorized_keysarchivo en la máquina remota deben ser editables solo por usted: rwx------y rwxr-xr-xestán bien, pero rwxrwx---no son buenos¹, incluso si usted es el único usuario en su grupo (si prefiere los modos numéricos: 700o 755no 775) .
  Si ~/.ssho authorized_keyses un enlace simbólico, se marca la ruta canónica (con enlaces simbólicos expandidos) .
• Su ~/.ssh/authorized_keysarchivo (en la máquina remota) debe ser legible (al menos 400), pero necesitará que también se pueda escribir (600) si le agrega más claves.
• Su archivo de clave privada (en la máquina local) debe ser legible y escribible solo por usted: rw-------es decir 600.
• Además, si SELinux está configurado para imponerse, es posible que deba ejecutarlo restorecon -R -v ~/.ssh(consulte, por ejemplo, el error de Ubuntu 965663 y el informe de errores de Debian # 658675 ; esto está parcheado en CentOS 6 ).

¹ _{Excepto en algunas distribuciones (Debian y derivados) que han parcheado el código para permitir la escritura del grupo si usted es el único usuario en su grupo.}

Si tiene acceso de root al servidor, la manera fácil de resolver tales problemas es ejecutar sshd en modo de depuración, emitiendo algo como /usr/sbin/sshd -d -p 2222en el servidor (puede ser necesaria la ruta completa al ejecutable de sshd which sshd) y luego conectarse desde el cliente ssh -p 2222 user@host. Esto obligará al demonio SSH a permanecer en primer plano y mostrar información de depuración sobre cada conexión. Busca algo como

debug1: trying public key file /path/to/home/.ssh/authorized_keys
...
Authentication refused: bad ownership or modes for directory /path/to/home/

Si no es posible utilizar un puerto alternativo, puede detener temporalmente el demonio SSH y reemplazarlo por uno en modo de depuración. Al detener el demonio SSH no se eliminan las conexiones existentes, por lo que es posible hacerlo a través de un terminal remoto, pero es algo arriesgado: si la conexión se interrumpe de alguna manera en el momento en que el reemplazo de depuración no se está ejecutando, queda bloqueado fuera de la máquina hasta que puedas reiniciarlo. Los comandos requeridos:

service ssh stop
/usr/sbin/sshd -d
#...debug output...
service ssh start

(Dependiendo de su distribución de Linux, la primera / última línea podría ser systemctl stop sshd.service/ en su systemctl start sshd.servicelugar).

¿Está encriptado el directorio de inicio? Si es así, para su primera sesión ssh deberá proporcionar una contraseña. La segunda sesión ssh para el mismo servidor funciona con la clave de autenticación. Si este es el caso, puede moverlo authorized_keysa un directorio sin cifrar y cambiar la ruta ~/.ssh/config.

Lo que terminé haciendo fue crear una /etc/ssh/usernamecarpeta, propiedad de nombre de usuario, con los permisos correctos, y coloqué el authorized_keysarchivo allí. Luego cambió la directiva AuthorizedKeysFile /etc/ssh/configa:

AuthorizedKeysFile    /etc/ssh/%u/authorized_keys

Esto permite que múltiples usuarios tengan este acceso ssh sin comprometer los permisos.

Después de copiar las llaves en la máquina remota y ponerlas dentro de la máquina, authorized_keysdebe hacer algo como esto:

ssh-agent bash
ssh-add ~/.ssh/id_dsa or id_rsa

Solo prueba estos siguientes comandos

1. ssh-keygen

   Presione la tecla Intro hasta que aparezca el mensaje

2. ssh-copy-id -i root@ip_address

   (Una vez pedirá la contraseña del sistema host)

3. ssh root@ip_address

   Ahora debería poder iniciar sesión sin ninguna contraseña

Enfrenté desafíos cuando el directorio de inicio en el control remoto no tiene los privilegios correctos. En mi caso, el usuario cambió el directorio de inicio a 777 para tener acceso local en el equipo. La máquina ya no podía conectarse con las teclas ssh. Cambié el permiso a 744 y comenzó a funcionar nuevamente.

SELinux en RedHat / CentOS 6 tiene un problema con la autenticación de clave pública , probablemente cuando se crean algunos de los archivos, selinux no está configurando sus ACL correctamente.

Para corregir manualmente las ACL de SElinux para el usuario root:

restorecon -R -v /root/.ssh

Nos encontramos con el mismo problema y seguimos los pasos de la respuesta. Pero todavía no funcionó para nosotros. Nuestro problema era que el inicio de sesión funcionaba desde un cliente pero no desde otro (el directorio .ssh estaba montado en NFS y ambos clientes usaban las mismas claves).

Así que tuvimos que ir un paso más allá. Al ejecutar el comando ssh en modo detallado obtienes mucha información.

ssh -vv user@host

Lo que descubrimos fue que la clave predeterminada (id_rsa) no fue aceptada y, en su lugar, el cliente ssh ofreció una clave que coincidía con el nombre de host del cliente:

debug1: Offering public key: /home/user/.ssh/id_rsa                                    
debug2: we sent a publickey packet, wait for reply                                        
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering public key: /home/user/.ssh/id_dsa                                    
debug2: we sent a publickey packet, wait for reply                                        
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering public key: user@myclient                                          
debug2: we sent a publickey packet, wait for reply                                        
debug1: Server accepts key: pkalg ssh-rsa blen 277                  

Obviamente, esto no funcionará desde ningún otro cliente.

Entonces, la solución en nuestro caso fue cambiar la clave rsa predeterminada a la que contenía user @ myclient. Cuando una clave es predeterminada, no se verifica el nombre del cliente.

Luego nos encontramos con otro problema, después del cambio. Aparentemente, las claves se almacenan en caché en el agente ssh local y obtuvimos el siguiente error en el registro de depuración:

'Agent admitted failure to sign using the key'

Esto se resolvió volviendo a cargar las claves en el agente ssh:

ssh-add

Sería una configuración de fallo SSH al final del servidor. Se debe editar el archivo sshd_config del lado del servidor. Situado en /etc/ssh/sshd_config. En ese archivo, cambie las variables

• 'sí' a 'no' para ChallengeResponseAuthentication, PasswordAuthentication, UsePAM

• 'no' a 'sí' para PubkeyAuthentication

Basado en http://kaotickreation.com/2008/05/21/disable-ssh-password-authentication-for-added-security/

Asegúrese de que AuthorizedKeysFileapunta a la ubicación correcta, use %ucomo marcador de posición para el nombre de usuario:

# /etc/ssh/sshd_config
AuthorizedKeysFile /home/%u/authorized_keys

Puede ser que solo necesite descomentar la línea:

AuthorizedKeysFile .ssh / certified_keys

Tenga en cuenta que debe volver a cargar el servicio ssh para que se realicen los cambios:

service sshd reload

Dos comentarios: esto sobrescribirá el archivo original. Simplemente copiaría la clave pública generada y haría algo como:

cat your_public_key.pub >> .ssh/authorized_keys

Esto agregará la clave que desea utilizar a la lista de claves preexistente. Además, algunos sistemas usan el archivo authorized_keys2, por lo que es una buena idea hacer un enlace duro que apunte entre authorized_keysy authorized_keys2, por si acaso.

Mi solución fue que la cuenta estaba bloqueada. Mensaje encontrado en / var / log / secure: Usuario no permitido porque la cuenta está bloqueada Solución: proporcione al usuario una nueva contraseña.

Me encontré con un problema similar y seguí los pasos con el modo de depuración.

/usr/sbin/sshd -d

Esto mostró el siguiente resultado

debug1: trying public key file /root/.ssh/authorized_keys
debug1: fd 4 clearing O_NONBLOCK
Authentication refused: bad ownership or modes for directory /root
debug1: restore_uid: 0/0
debug1: temporarily_use_uid: 0/0 (e=0/0)
debug1: trying public key file /root/.ssh/authorized_keys2
debug1: Could not open authorized keys '/root/.ssh/authorized_keys2': No such file or directory
debug1: restore_uid: 0/0
Failed publickey for root from 135.250.24.32 port 54553 ssh2
debug1: userauth-request for user root service ssh-connection method gssapi-with-mic

Fue realmente confuso

[root@sys-135 ~]# ls -l /
drwxrwxrwx.   2 root root     4096 Dec 14 20:05 bin
drwxrwxrwx.   5 root root     1024 May  6  2014 boot
drwxrwxrwx.   2 root root     4096 Dec  2  2013 cgroup
drwxrwxrwx.  10 root root     1024 Sep 25 23:46 data
drwxrwxrwx. 124 root root    12288 Dec 16 10:26 etc
drwxrwxrwx.  11 root root     4096 Jan 14  2014 lib
drwxrwxrwx.   9 root root    12288 Dec 14 20:05 lib64
drwxrwxrwx.   2 root root    16384 Jan 10  2014 lost+found
drwxrwxrwx.   2 root root     4096 Jun 28  2011 media
drwxr-xr-x.   2 root root        0 Dec 10 14:35 misc
drwxrwxrwx.   2 root root     4096 Jun 28  2011 mnt
drwxrwxrwx.   4 root root     4096 Nov 24 23:13 opt
dr-xr-xr-x. 580 root root        0 Dec 10 14:35 proc
drwxrwxrwx.  45 root root     4096 Dec 16 10:26 root

Mostró que el directorio raíz tenía permisos para cada uno. Lo cambiamos para que otros no tuvieran permisos.

[root@sys-135 ~]# chmod 750 /root

La autenticación de clave comenzó a funcionar.

En el archivo / etc / selinux / config, el cambio de SELINUX a desactivado hace que el ssh sin contraseña funcione correctamente.

Anteriormente, puedo hacerlo de una manera. Ahora desde ambos lados puedo hacer ssh sin contraseña.

Una cosa que me equivoqué fue la propiedad de mi directorio de inicio en el sistema del servidor. El sistema del servidor se configuró como predeterminado: predeterminado, entonces yo:

chown -R root:root /root

Y funcionó. Otra solución económica es deshabilitar StrictModes: StirctModes no. en sshd_config. Esto al menos le dirá si el intercambio de claves y los protocolos de conexión son buenos. Entonces puedes ir a cazar los malos permisos.

Para mí, la solución era opuesta a la de Wojtek Rzepala : no me di cuenta de que todavía estaba usando authorized_keys2, lo que ha quedado en desuso . Mi configuración ssh dejó de funcionar en algún momento, presumiblemente cuando se actualizó el servidor. Renombrar .ssh/authorized_keys2como .ssh/authorized_keyssolucionó el problema.

D'oh!

En el pasado, encontré algunos tutoriales que describen cómo lograr una configuración ssh sin contraseña, pero algunos están tristemente equivocados.
Comencemos de nuevo y verifiquemos cada paso:

1. DEL CLIENTE - Generar clave: la clave ssh-keygen -t rsa
   pública y privada ( id_rsa.puby id_rsa) se almacenará automáticamente en el ~/.ssh/directorio.
   La configuración será más fácil si usa una frase de contraseña vacía. Si no está dispuesto a hacer eso, siga esta guía, pero también revise el punto siguiente.
   
   
2. DEL CLIENTE - Copiar clave pública al servidor : ssh-copy-id user@server
   la clave pública del cliente se copiará en la ubicación del servidor ~/.ssh/authorized_keys .
   
   
3. DE CLIENTE - Conéctese al servidor:ssh user@server
   
   

Ahora, si aún no funciona después de los 3 pasos descritos, intentemos lo siguiente:

• Verifique los ~/sshpermisos de carpeta en la máquina cliente y servidor .
• Compruebe /etc/ssh/sshd_configen el servidor para asegurarse de que RSAAuthentication, PubkeyAuthenticationy las UsePAMopciones no están deshabilitadas, se pueden habilitar de forma predeterminada con yes.
• Si ingresó una frase de contraseña al generar su clave de cliente, puede intentar ssh-agenty ssh-addlograr conexiones sin contraseña en su sesión.
• Compruebe el contenido de /var/log/auth.logen el servidor para encontrar el problema por el cual se omite la autenticación de clave.

Estaba teniendo exactamente el mismo problema con PuTTY conectándose a una máquina Ubuntu 16.04. Fue desconcertante porque el programa pscp de PuTTY funcionaba bien con la misma clave (y la misma clave funcionaba en PuTTY para conectarse a otro host).

Gracias al valioso comentario de @UtahJarhead, revisé mi archivo /var/log/auth.log y encontré lo siguiente:

sshd[17278]: userauth_pubkey: key type ssh-dss not in PubkeyAcceptedKeyTypes [preauth]

Resulta que las versiones más nuevas de OpenSSH no aceptan claves DSA por defecto. Una vez que cambié de una clave DSA a una clave RSA, funcionó bien.

Otro enfoque: esta pregunta analiza cómo configurar el servidor SSH para aceptar claves DSA: https://superuser.com/questions/1016989/ssh-dsa-keys-no-longer-work-for-password-less-authentication?lq = 1

Estos pasos deberían ayudarte. Lo uso regularmente entre muchas máquinas Ubuntu 10.04 de 64 bits.

[ ! -f ~/.ssh/id_rsa.pub ] && ssh-keygen -t rsa;
ssh <username>@<remote_machine> 'mkdir -p ~/.ssh'
cat ~/.ssh/id_rsa.pub | ssh <username>@<remote_machine> 'cat >> ~/.ssh/authorized_keys'

podría poner esto en un script con algunas indicaciones e invocarlo como

script_name username remote_machine

Tuve un problema similar con ssh. En mi caso, el problema fue que instalé hadoop cloudera (desde rpm en centos 6) y creó hdfs de usuario con el directorio de inicio

/var/lib/hadoop-hdfs(no estándar /home/hdfs)

Cambié en / etc / passwd /var/lib/hadoop-hdfsa /home/hdfs, moví el directorio de inicio a una nueva ubicación y ahora puedo conectarme con la autenticación de clave pública.

Sólo tenía este mismo problema, y para mí la solución era establecer UsePAMa no. Verá, incluso con PasswordAuthenticationset to no, todavía obtendrá keyboard-interactive, y en mi caso, mi programa ssh local siguió por defecto, por alguna razón.

Antecedentes adicionales para ayudar a cualquier persona con la misma situación: me estoy conectando desde un host que ejecuta Dropbear a uno que ejecuta OpenSSH. Con PasswordAuthenticationy UsePAMambos configurados noen la máquina remota, recibiré el siguiente mensaje si ingreso ssh user@server:

ssh: Connection to user@server:22 exited: Disconnect received

Al proporcionar el archivo de identidad -i, todo funciona como se esperaba.

Puede haber un poco más de información aquí.

Después de verificar los permisos y probar varias otras soluciones enumeradas aquí, finalmente eliminé el directorio ssh del servidor y configuré nuevamente mi clave pública.

Comandos del servidor:

# rm -rf ~/.ssh

Comandos locales:

# ssh-copy-id [email protected]        # where <user> is your username and <192.168.1.1> is the server IP

En el servidor:

$ ls -lh /home
$ sudo chmod 700 /home/$USER

Fue directory permission issue. Era 777 en el servidor, entonces I changed it back to 700. Este es fixedmi problema ssh password less login failureincluso después de copiar $USER/.ssh/id_rsa.pubal servidor $USER/.ssh/authorized_keys.

Sin embargo, otra opción es una variante de @Jagadish 's respuesta : para straceel demonio ssh.

Tiene la ventaja significativa de que no necesitamos detener el sshd, lo que puede resultar en un bloqueo completo si algo sale mal.

Primero, encontramos el pid del proceso sshd principal. Aquí podemos verlo ejecutando a pstree -pa|less.

  |-sshd,633 -D  <-- THIS IS WHAT WE WANT!
  |   `-sshd,21973   
  |       `-sshd,21996    
  |           `-bash,22000
  |               `-screen,638 -r

Después de saber que el pid es 633, podemos stracehacerlo, siguiendo a sus hijos:

strace -p 633 -s 4096 -f -o sux

El resultado será que todo lo que este sshd, y sus procesos secundarios han hecho, se dividirá en el archivo nombrado suxen el directorio local.

Luego reproduce el problema.

Tendrá una lista masiva de registro de llamadas del núcleo, que en su mayoría es incomprensible / irrelevante para nosotros, pero no en todas partes. En mi caso, lo importante fue esto:

6834  sendto(4, "<38>Jan 15 18:49:21 sshd[6834]: User cica not allowed because account is locked\0", 84, MSG_NOSIGNAL, NULL, 0) = 84

Fue mentos, que el sshd intentó registrar el mensaje El usuario cica no está permitido porque la cuenta está bloqueada , solo que no pudo, porque el registro no es lo suficientemente detallado para eso. Pero ya sabemos, se rechazó la clave pública porque la cuenta estaba bloqueada.

Todavía no es una solución: ahora necesitamos googlear, lo que significa una "cuenta bloqueada" en el caso del sshd. Lo más probable es que sea algo trivial /etc/passwd, /etc/shadowmágico, pero lo importante está hecho: el problema no es misterioso, sino fácil de depurar / buscar en Google.

En mi caso, tenía todos los permisos correctos e incluso cuando ejecuté ssh con la bandera -vvv no pude entender cuál era el problema.

Entonces generé un nuevo certificado en un host remoto

ssh-keygen -t rsa -C "[email protected]"

y copié las claves generadas en la máquina local y agregó una nueva clave pública a ~ / .ssh / Authorizedkeys en el host remoto

cat id_rsa.pub >> authorized_keys

El uso de claves generadas desde la conexión remota de máquina host ahora funciona. Entonces, si otras soluciones fallan, esta es otra cosa para probar.

Mi escenario fue que tengo un servidor NAS en el que creé un backupbotusuario, después de la creación de mi cuenta principal, que pudo iniciar sesión para crear inicialmente el backupbotusuario. Después de jugar sudo vim /etc/ssh/sshd_configy crear el backupbotusuario, vimpuede crear, al menos en Ubuntu 16.04, y según su ~/.vimrcconfiguración, un archivo de intercambio que queda de la edición de su sesión de vim /etc/ssh/sshd_config.

Comprueba si /etc/ssh/.sshd_config.swpexiste : y si lo elimina, reinicia el sshddemonio:

$ sudo rm /etc/ssh/.sshd_config.swp
$ sudo service sshd restart

Esto resolvió mágicamente mi problema. Anteriormente había verificado todos mis permisos e incluso las huellas digitales RSA de las claves públicas y privadas. Esto es extraño y probablemente un error con sshd, específicamente esta versión:

OpenSSH_7.4p1 Ubuntu-10, OpenSSL 1.0.2g 1 de marzo de 2016