SSH sigue omitiendo mi clave pública y solicitando una contraseña

52

Cada vez que accedo a mi servidor remoto, necesito proporcionar la contraseña. Copié mi clave pública (id_dsa.pub) en el servidor remoto usando:

ssh-copy-id -i id_dsa.pub user@server

Verifiqué que se agregó correctamente a autorizado_claves. Todos los permisos de archivo / directorio son correctos:

~user 755
~user/.ssh 700
~user/.ssh/authorized_keys 640
~user/.ssh/id_dsa.pub 644

El campo PasswordAuthentication en / etc / ssh / sshd_config se establece en yes. Puse el sshd en modo de depuración y agregué el interruptor detallado al comando ssh. Tengo la impresión de que el servidor no intentó usar id_pub.dsa debido a la línea

Skipping ssh-dss key: ........... not in PubkeyAcceptedKeyTypes

No hay disco cifrado en el lado del servidor. ¿Alguna idea de cómo progresar? Aquí está la información de depuración del demonio ssh:

sudo /usr/sbin/sshd -d
====
debug1: sshd version OpenSSH_6.6.1, OpenSSL 1.0.1f 6 Jan 2014
debug1: key_parse_private2: missing begin marker
debug1: read PEM private key done: type RSA
debug1: private host key: #0 type 1 RSA
debug1: key_parse_private2: missing begin marker
debug1: read PEM private key done: type DSA
debug1: private host key: #1 type 2 DSA
debug1: key_parse_private2: missing begin marker
debug1: read PEM private key done: type ECDSA
debug1: private host key: #2 type 3 ECDSA
debug1: rexec_argv[0]='/usr/sbin/sshd'
debug1: rexec_argv[1]='-d'
Set /proc/self/oom_score_adj from 0 to -1000
debug1: Bind to port 22 on 0.0.0.0.
Server listening on 0.0.0.0 port 22.
debug1: Bind to port 22 on ::.
Server listening on :: port 22.
debug1: Server will not fork when running in debugging mode.
debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8
debug1: inetd sockets after dupping: 3, 3
Connection from xxx port 63521 on yyy port 22
debug1: Client protocol version 2.0; client software version OpenSSH_7.1
debug1: match: OpenSSH_7.1 pat OpenSSH* compat 0x04000000
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.3
debug1: permanently_set_uid: 115/65534 [preauth]
debug1: list_hostkey_types: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256 [preauth]
debug1: SSH2_MSG_KEXINIT sent [preauth]
debug1: SSH2_MSG_KEXINIT received [preauth]
debug1: kex: client->server chacha20-poly1305@openssh.com <implicit> none [preauth]
debug1: kex: server->client chacha20-poly1305@openssh.com <implicit> none [preauth]
debug1: expecting SSH2_MSG_KEX_ECDH_INIT [preauth]
debug1: SSH2_MSG_NEWKEYS sent [preauth]
debug1: expecting SSH2_MSG_NEWKEYS [preauth]
debug1: SSH2_MSG_NEWKEYS received [preauth]
debug1: KEX done [preauth]
debug1: userauth-request for user damian service ssh-connection method none [preauth]
debug1: attempt 0 failures 0 [preauth]
debug1: PAM: initializing for "damian"
debug1: PAM: setting PAM_RHOST to "freebox-server.local"
debug1: PAM: setting PAM_TTY to "ssh"
Connection closed by xxxx [preauth]
debug1: do_cleanup [preauth]
debug1: monitor_read_log: child log fd closed
debug1: do_cleanup

Aquí está el resultado detallado ssh:

$ ssh -v user@server
OpenSSH_7.1p1, OpenSSL 1.0.2d 9 Jul 2015
debug1: Connecting to server [xxxx] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_rsa-cert type -1
debug1: identity file /home/user/.ssh/id_dsa type 2
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.3
debug1: match: OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.3 pat OpenSSH_6.6.1* compat 0x04000000
debug1: Authenticating to server:22 as 'user'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client chacha20-poly1305@openssh.com <implicit> none
debug1: kex: client->server chacha20-poly1305@openssh.com <implicit> none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:v4BNHM0Q33Uh6U4VHenA9iJ0wEyi8h0rFVetbcXBKqA
debug1: Host 'server' is known and matches the ECDSA host key.
debug1: Found key in /home/user/.ssh/known_hosts:2
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
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: Trying private key: /home/user/.ssh/id_rsa
debug1: Skipping ssh-dss key /home/user/.ssh/id_dsa for not in PubkeyAcceptedKeyTypes
debug1: Trying private key: /home/user/.ssh/id_ecdsa
debug1: Trying private key: /home/user/.ssh/id_ed25519
debug1: Next authentication method: password
user@server's password:
ssh  password  authentication 
— Damo
fuente
1
Vea también superuser.com/q/1016989/93541 para el mismo problema (y esencialmente la misma solución).
— DW
Tenga en cuenta que si sshd_config en el destino tiene PubkeyAuthentication no , siempre se le solicitará una contraseña. Configúrelo en yes y reinicie sshd (en el host de destino) para habilitar la autenticación de clave pública.
— C. Kelly

Respuestas:

84

La nueva versión de openssh (7.0+) desaprobó las claves DSA y no utiliza las claves DSA de manera predeterminada (no en el servidor o el cliente). Ya no se prefiere usar las claves , por lo que si puede, recomendaría usar claves RSA siempre que sea posible.

Si realmente necesita usar claves DSA, debe permitirlas explícitamente en la configuración de su cliente usando

PubkeyAcceptedKeyTypes +ssh-dss

Debería ser suficiente para poner esa línea ~/.ssh/config, ya que el mensaje detallado está tratando de decirte.

— Jakuje
fuente
55
+1, pero un mejor consejo sería utilizar otro tipo de clave no obsoleto ...
— jasonwryan
@jasonwryan Gracias por comentar. Ciertamente. Actualizaré la respuesta.
— Jakuje
Gracias Jakuje! Eso tiene sentido, no me di cuenta de que dsa era viejo. Generé un nuevo par de claves ssh-keygenrsa es el valor predeterminado ahora. Intentaré iniciar sesión con esto desde la otra máquina mañana.
— Damo
Si ~/.ssh/configno existe, simplemente créelo. Y recuerda que para establecer los permisos corect: chmod 600 ~/.ssh/config.
— Florian Brucker
@knb no hagas eso. Evitará el uso de otros algoritmos en el futuro, ya que eliminó todos los algoritmos de curva elíptica.
— Jakuje
2

En mi caso, estaba teniendo este problema porque otro usuario había cambiado la AuthorizedKeysFileubicación. Como no había authorized_keysotros usuarios en esta ubicación, el inicio de sesión sería la contraseña predeterminada, aunque authorized_keysexistiera con los permisos correctos en el directorio de inicio predeterminado.

AuthorizedKeysFile   /etc/ssh/%u/authorized_keys

Comentó esta salida de línea modificada y reinició el servicio sshd para volver a la configuración predeterminada, lo que permitió a otros usuarios autenticarse usando sus claves.

— GotGame
fuente
Acabo de resolver un problema similar en un sistema RHEL7 donde el contexto SELinux no se inicializó correctamente en el homedir del usuario, por lo que ssh no pudo leer el archivo de claves autorizado a pesar de los permisos estándar. Finalmente terminé corriendo restorecon -Rv /homepara arreglarlo para los otros usuarios que también estaban configurados incorrectamente en el mismo sistema.
— dannysauer
1

Intenté la respuesta de Jakuje Sin suerte. Pero entiendo el problema desde allí. Intenté agregar comentarios, pero necesito reputación por eso agregar respuestas.

Pero el archivo de configuración para mí / etc / ssh / ssh_config

  1. sudo nano /etc/ssh/ssh_config
  2. PubkeyAcceptedKeyTypes +ssh-dss Se agregó esta línea en la parte inferior.
  3. Guardar e intentado de nuevo.

¡Trabajó!

— SWAPNIL DEWALKAR
fuente
1

Solo para resumir lo que hice para SSH a Raspberry Pi .

En la máquina del servidor (raspberry Pi): 

$ ip addr show

o simplemente ip a, esto mostrará la dirección IP de la máquina Pi - host_ip

$ mkdir .ssh

En la máquina del cliente (ubuntu):

$ ssh-keygen -t rsa

Crédito a @Jakuje arriba. Inicialmente estaba usando ssh-keygen -t dsa para la generación de claves, y ssh seguía pidiéndome contraseña. ssh -v ip-address no me da mucha información útil, hasta que vi la respuesta de @ Jakuje

$ cat .ssh/id_rsa.pub | ssh user_id@host_ip 'cat >> ~/.ssh/authorized_keys'

reemplace user_id y host_ip, cuando se le solicite, proporcione la contraseña para la máquina Pi

$ ssh user@ip_address

inició sesión correctamente en PI, no más contraseña

— VictorL
fuente
0

dsa no funcionó para mí rsa lo hizo.

ssh-keygen -t rsa -P '' -f ~/.ssh/id_rsa
cat /Users/user_name/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys

Y puedo ssh sin contraseña.

— rodya
fuente
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.