
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/sshd
entre el nuevo servidor y el otro servidor normal, es lo mismo. Luego simplemente copié el archivo /etc/ssh/sshd_config
del 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 .ssh
carpeta 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 chown
el comando si es necesario).
También verifique la authorized_keys
carpeta y el archivo en el servidor (probablemente en /root/.ssh
la 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_config
y 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 775
inferiores 0755
o inferiores.
La ruta completa al archivo Authorized_keys, es decir, /home/user/.ssh/
debe ser 0755
o inferior.
Respuesta3
Solucioné mi propio caso de este error eliminándolo id_rsa.pub
de .ssh.
Lo copié id_rsa
de otra máquina y lo distribuí entre varios clientes ficticios. Por lo tanto, id_rsa
y id_rsa.pub
en realidad eran claves diferentes que impedían el uso de id_rsa
por 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 777
ni 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.