El servidor OpenSSH se niega a aceptar la autenticación de claves

El servidor OpenSSH se niega a aceptar la autenticación de claves

Intenté utilizar la autenticación de clave pública en mi nuevo servidor y encontré este problema.

$ ssh -v -i .ssh/server 192.168.1.100
OpenSSH_5.6p1, OpenSSL 0.9.8r 8 Feb 2011
debug1: Reading configuration data .ssh/config
debug1: Applying options for *
debug1: Reading configuration data /etc/ssh_config
debug1: Applying options for *
debug1: Connecting to 192.168.1.100 [192.168.1.100] port 22.
debug1: Connection established.
debug1: identity file .ssh/server type -1
debug1: identity file .ssh/server-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.8p1 Debian-1ubuntu3
debug1: match: OpenSSH_5.8p1 Debian-1ubuntu3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.6
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr 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 '192.168.1.100' is known and matches the RSA host key.
debug1: Found key in .ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
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: .ssh/server
debug1: read PEM private key done: type RSA
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: password

y luego tengo que ingresar mi contraseña para iniciar sesión.

Pero, si ya tengo una sesión conectada a ese servidor (que está conectado mediante contraseña), entonces la siguiente conexión usa autenticación de clave para evitar el ingreso de contraseña.

Si no hay una conexión SSH ya establecida, no puedo conectarme sin ingresar la contraseña.

Esto es realmente extraño para mí, verifiqué el MD5 /usr/sbin/sshdentre el nuevo servidor y el otro servidor normal, es lo mismo. Luego simplemente copié el archivo /etc/ssh/sshd_configdel otro servidor normal al nuevo servidor y ejecuté service ssh restart. El problema todavía existe.

¿Cómo se supone que voy a solucionar esto?

Respuesta1

Verifique que su .sshcarpeta y los archivos que contiene en la máquina cliente solo sean legibles por el propietario ( chmod -R 600 .ssh) y que el propietario sea el correcto para la carpeta y los archivos (use chownel comando si es necesario).

También verifique la authorized_keyscarpeta y el archivo en el servidor (probablemente en /root/.sshla carpeta de inicio del usuario que intenta iniciar sesión) para asegurarse de que sus permisos y propietario estén configurados de la misma manera.


Editar: basado en más comentarios (¡y algunas conjeturas!): ¿Puede verificar /etc/ssh/sshd_configy ver si el siguiente parámetro está configurado como se muestra a continuación? Si no, intenta editarlo.

AuthorizedKeysFile /home/%u/.ssh/authorized_keys

Tenga en cuenta que esto supone que no inicia sesión de forma remota como root

Respuesta2

En mi caso, los permisos en el directorio de inicio eran 775inferiores 0755o inferiores.

La ruta completa al archivo Authorized_keys, es decir, /home/user/.ssh/debe ser 0755o inferior.

Respuesta3

Solucioné mi propio caso de este error eliminándolo id_rsa.pubde .ssh.

Lo copié id_rsade otra máquina y lo distribuí entre varios clientes ficticios. Por lo tanto, id_rsay id_rsa.puben realidad eran claves diferentes que impedían el uso de id_rsapor completo.

Sin embargo, no hay ningún mensaje de error que lo indique claramente. Lo descubrí esencialmente por accidente, intentando que las diferentes máquinas estuvieran en un estado idéntico.

Respuesta4

Después de molestar mucho obtuve la solución del problema:

El directorio de inicio del usuario no debe tener permiso 777ni poder escribirse en todo el mundo. Si es el caso, la verificación de la clave SSH fallará y deberá ingresar una contraseña para iniciar sesión.

información relacionada