SSH aún solicita contraseña después de configurar la autenticación basada en clave


10

He creado con éxito una autenticación basada en clave para el usuario root de mi máquina A a mi máquina B.

Ahora, creé un nuevo usuario en la máquina B, igual que en la máquina A, llamémoslo USER. Creé un directorio de inicio para él en la máquina B /home/USERy quiero crear una autenticación basada en claves para él de la máquina A a la máquina B.

Entonces, corrí en una máquina

  1. ssh-keygen -t rsa, aceptó todos los caminos, así /home/USER/.ssh/id_rsay sin frases
  2. ssh-copy-id -i /home/USER/.ssh/id_rsa.pub USER@BmachinesIP, ingresé la contraseña y recibí un masaje

Ahora intenta iniciar sesión en la máquina bla bla bla

Entonces todo parece estar bien.

Pero cuando intenté conectarme, ssh USER@BmachinesIPme pidieron una contraseña. Traté de ver el registro y corrí ssh -vvv USER@BmachinesIPy aquí hay una parte de la salida:

debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /home/USER/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/USER/.ssh/id_dsa
debug3: no such identity: /home/USER/.ssh/id_dsa
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
USER@BmachinesIP's password:

Entonces, ¿alguien puede decirme qué he hecho mal o qué debo cambiar? Tal vez el problema está en los permisos, aquí están:

en una máquina:

drwx------  2 USER USER    SIZE DATE TIME .ssh
-rw-------  1 USER USER 1675 2011-10-31 14:36 id_rsa
-rw-r--r--  1 USER USER 413 2011-10-31 14:36 id_rsa.pub

y en la máquina B:

drwx------  2 USER defaultGroup    SIZE DATE TIME .ssh
-rw-------    1 USER defaultGroup    SIZE DATE TIME authorized_keys

Respuestas:


13

He encontrado una solución. Hubo un problema en los permisos.

/home/USER en la máquina remota se le concedieron todos los permisos, pero para la autenticación basada en clave se debe establecer en 755


2
Guau. Es sorprendente que haya cero resultados de depuración sobre los permisos a pesar de que son centrales para la configuración de clave pública adecuada.
jchook

Wow, tienes razón. Ahora está funcionando ... aunque realmente quiero mantener el permiso que tenía originalmente (775). ¿Alguna pista sobre cómo cambiar eso?
Pablo Olmos de Aguilera

Parece que no hay forma, solo la solución sería establecer StrictModes no en sshd_config. : /.
Pablo Olmos de Aguilera

2
Esencialmente necesita estos permisos: chmod o-w ~/; chmod 700 ~/.ssh; chmod 600 ~/.ssh/authorized_keysentonces funciona. Copiado de la respuesta de Maxime R. de aquí: askubuntu.com/questions/54670/passwordless-ssh-not-working
erik

2
He realizado todos estos cambios de permisos, y todavía me pide una contraseña cuando ssh. También he verificado que la clave privada es la misma en ambas máquinas (Ubuntu). Bastante perplejo.
Amalgovinus

2

El mismo problema para mí instalación fresca de CentOS7.

1. verifique los permisos de directorio de inicio y los permisos ~ / .ssh y ~ / .ssh / certified_keys (según @erik)

chmod o-w ~/; chmod 700 ~/.ssh; chmod 600 ~/.ssh/authorized_keys

2. verifique / etc / ssh / sshd_config settings && service sshd restart (después de cada edición) Útil: intente "LogLevel VERBOSE" en sshd_config.

Todavía recibí un mensaje de contraseña después de verificar que todo estaba bien.

Ejecute el cliente ssh con los registros -vvv:

debug3: send_pubkey_test 
debug2: we sent a publickey packet, wait for reply

Registros del servidor (/ var / log / secure):

Failed publickey for * from * port * ssh2: RSA *

El servidor ssh no envía más información de error al cliente, ya que eso sería un riesgo de seguridad.

Si ejecuté sshd en un puerto diferente 'sshd -p 5555 -d'. La llave funcionó. Inicio de sesión sin contraseña ok. WTF?

Luego deshabilité selinux (configuré SELINUX = deshabilitado en / etc / selinux / config) y reinicié. El inicio de sesión sin contraseña funcionó bien.

mi configuración actual de sshd_config de trabajo:

[root@hp-bl-05 ~]# grep -vE "^#|^$" /etc/ssh/sshd_config  
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
SyslogFacility AUTHPRIV
LogLevel VERBOSE
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile  .ssh/authorized_keys
HostbasedAuthentication yes
PasswordAuthentication yes
ChallengeResponseAuthentication no
GSSAPIAuthentication no
GSSAPICleanupCredentials no
UsePAM yes
X11Forwarding yes
UseDNS no
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE
AcceptEnv XMODIFIERS
Subsystem   sftp    /usr/libexec/openssh/sftp-server

Por lo tanto, sería bueno saber si podríamos cambiar algo pequeño en selinux para que el inicio de sesión ssh sin contraseña funcione. ¿Alguien puede mejorar la respuesta?


0

La solución no es deshabilitar SELinux, sino arreglar los permisos SELinux del directorio de usuarios. El contexto del directorio de usuarios debe establecerse en user_home_t.

Verificar,

$ sudo ls -Z /home/

Si el contexto para su directorio de usuarios es diferente user_home_t, SELinux no permitiría SSH a través de la clave pública en ese directorio de usuario para ese usuario.

Arreglar,

$ sudo semanage fcontext -a -t user_home_t /home/azureuser
$ sudo restorecon -vvRF /home/azureuser

El inicio de sesión basado en clave ahora debería funcionar.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.