Comportamiento extraño en el inicio de sesión de clave pública SSH

Estoy realmente atrapado aquí. He estado intentando ingresar a mi servidor ec2 desde local con una clave pública pero no funciona. -> Me dan permiso denegado (clave pública).

La configuración es la siguiente: Local: par de claves públicas generadas y contenido copiado de id_rsa.pub. Remoto: ssh-ed en mi servidor EC2 con el archivo PEM y pegué los contenidos id_rsa.pub en una nueva línea de archivos de claves autorizadas en la carpeta .ssh.

¿Debería funcionar bien? Noté que un error común son los permisos, pero el mío parece estar configurado correctamente:

Permisos remotos:

drwx------ 2 ec2-user ec2-user  4096 Jul 23 04:00 .ssh

y en .ssh:

-rw-r--r-- 1 ec2-user ec2-user  404 Jul 24 03:19 id_rsa.pub
-rw------- 1 ec2-user ec2-user 1679 Jul 24 03:19 id_rsa
-rw------- 1 ec2-user ec2-user  529 Jul 26 20:53 authorized_keys

Local:

drwx------    10 robvanhaaren  staff    340 Jul 26 18:43 .ssh

y en .ssh:

-rw-r--r--  1 robvanhaaren  staff   404 Jul 26 21:28 id_rsa.pub
-rw-------  1 robvanhaaren  staff  1766 Jul 26 21:28 id_rsa
-rw-r--r--  1 robvanhaaren  staff  5987 Jul 26 21:29 known_hosts

Pero cuando corro:

Robs-MacBook-Air-2:.ssh robvanhaaren$ ssh ec2-54-85-62-99.compute-1.amazonaws.com -l ec2-user -v

vuelve:

OpenSSH_5.9p1, OpenSSL 0.9.8y 5 Feb 2013
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: Connecting to ec2-54-85-62-99.compute-1.amazonaws.com [54.85.62.99] port 22.
debug1: Connection established.
debug1: identity file /Users/robvanhaaren/.ssh/id_rsa type 1
debug1: identity file /Users/robvanhaaren/.ssh/id_rsa-cert type -1
debug1: identity file /Users/robvanhaaren/.ssh/id_dsa type -1
debug1: identity file /Users/robvanhaaren/.ssh/id_dsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.2
debug1: match: OpenSSH_6.2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9
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: Server host key: RSA 7a:d3:6c:7f:64:5d:b1:7b:2e:bb:73:0c:ce:0c:17:77
debug1: Host 'ec2-54-85-62-99.compute-1.amazonaws.com' is known and matches the RSA host key.
debug1: Found key in /Users/robvanhaaren/.ssh/known_hosts:15
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
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/robvanhaaren/.ssh/id_rsa
debug1: Authentications that can continue: publickey
debug1: Trying private key: /Users/robvanhaaren/.ssh/id_dsa
debug1: No more authentication methods to try.
Permission denied (publickey).

Lo extraño es que PUEDO iniciar sesión con clave pública en el servidor desde mi otro servidor ec2. Entonces, el problema parece estar en mi máquina local , no en la remota.

¡Por favor ayuda!

— Rob360
fuente

¿Lo has comprobado /var/log/auth.log? ¿Hay algún registro relevante?

— Valmiky Arquissandas

¿Está utilizando el mismo conjunto de claves para iniciar sesión desde su otro servidor ec2?

— heavyd

tal vez no agregaste correctamente a claves_autorizadas. ssh-copy-id puede hacerlo automáticamente. Primero habilite el inicio de sesión de usuario / pase, es decir, PasswordAuthentication yesen sshd_config, y luego puede usarlo, ssh-copy-id user@hostluego se agregará automáticamente a claves_autorizadas, y la próxima vez que use la clave, y puede desactivar el inicio de sesión de usuario / paso si lo desea

— barlop

Respuestas:

Los problemas de SSH pueden ser una molestia. Siempre empiezo con lo siguiente. Tengo los comandos guardados en una hoja de trucos para que nunca tenga que temer los errores tipográficos.

chmod 700 ~/.ssh && chmod 600 ~/.ssh/* \
&& chmod 644 ~/.ssh/authorized_keys \
&& chown -r <username>:<username> /home/<username>/.ssh \
&& chown -r <username>:<username> /home/<username>/.ssh/*

Si eso no funciona, eliminaría autorizado_keys y volvería a crearlo (tenga en cuenta la propiedad y los permisos), asegurándome de copiar el contenido del bloc de notas u otro editor de texto adecuado. Wordpad y otros editores gordos pueden estropear las teclas. También puede eliminar la entrada del host remoto del archivo known_hosts. Recuerdo tener que hacer eso una vez por algo.

— Alex Atkinson
fuente

escribes "Si eso no funciona, eliminaría autorizado_" <- te refieres a autorizado_claves

— barlop

Sí, autorizado_keys ^ _ ^ (edición)

— Alex Atkinson

Parece que los archivos autorizado_claves e id_rsa.pub son de diferentes tamaños; creo que ese es el problema aquí.

— Jacob Hume

@JacobHume deberías dar más detalles sobre esa declaración, ya que autorizada_keys pueden tener esa id_rsa.pub y más

— barlop

Escribe "También puede eliminar la entrada del host remoto del archivo known_hosts" <- o remueve el archivo known_hosts. Aunque el tema known_hosts no es el tema en su pregunta .. La cuestión known_hosts es un error de dfiferent algo acerca de un cambio de clave ..

— barlop

Asegúrese de marcar /var/log/auth.logcomo se indica en el comentario. Casi siempre encontrarás tu respuesta allí.

Tengo estos permisos establecidos para mis servidores y localmente:

Servidor

drwx------ remoteuser group ~/.ssh
-rw------- remoteuser group ~/.ssh/authorized_keys

En la zona

drwx------ user group ~/.ssh
-rw------- user group ~/.ssh/id_rsa
-rw----r-- user group ~/.ssh/id_rsa.pub

— Overbryd
fuente

Por curiosidad, ¿por qué authorized_keysotros archivos son legibles? ¿No se authorized_keyssupone que el archivo es 600?

— JW0914

Buena atrapada. Esta es una respuesta muy antigua, y probablemente debería editarla.

— Overbryd