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.