Pregunta ¿Por qué obtengo "Permiso denegado (publickey)" cuando intento SSH de Ubuntu local a un servidor de Amazon EC2?


Tengo una instancia de una aplicación que se ejecuta en la nube en la instancia de Amazon EC2, y necesito conectarlo desde mi Ubuntu local. Funciona bien en uno de ubuntu local y también portátil. Recibí el mensaje "Permiso denegado (publickey)" al intentar acceder a SSH a EC2 en otro Ubuntu local. Es tan extraño para mí.

Estoy pensando en algún tipo de problema con la configuración de seguridad en Amazon EC2, que tiene acceso IP limitado a una instancia o certificado que puede necesitar regenerarse.

¿Alguien sabe alguna solución?


213
2017-07-13 07:38


origen


"Antes trabajaba antes" - antes qué? - womble♦
Tengo una instancia de Elastic Beanstalk EC2. A partir de agosto de 2013, la solución fue acceder a la instancia como usuario usuario de ec2 que hizo que el error de Permiso denegado (publicKey) desapareciera. A saber: ssh -i ./mike-key-pairoregon.pem ec2-user@ec2-some-address.us-west-2.compute.amazonaws.com. Por supuesto que tienes que todas las otras cosas según stackoverflow.com/questions/4742478/… - mikemay
Obtendrá este problema si tiene el nombre de usuario incorrecto especificado. Los documentos aws (docs.aws.amazon.com/AWSEC2/latest/UserGuide/…) actualmente doy un ejemplo con el nombre de usuario ec2-user [ssh -i /path/my-key-pair.pem ec2-user@ec2-198-51-100-1.compute-1.amazonaws.com], mientras que mi ( antiguo) ubuntu box tiene un nombre de usuario de ubuntu, por lo tanto, cuando utilicé el ejemplo, recibí este error, cambiando el nombre de usuario correcto se resuelve. - david.barkhuizen
@ david.barkhuizen, tu comentario me ayudó. Tuve un problema similar; Resultó que tenía que ver con el nombre de usuario. Gracias. - NaijaProgrammer


Respuestas:


Lo primero que hay que hacer en esta situación es usar el -v opción a ssh, para que pueda ver qué tipos de autenticación se intentan y cuál es el resultado. ¿Eso ayuda a iluminar la situación?

En la actualización de su pregunta, menciona "en otro Ubuntu local". ¿Ha copiado la clave privada ssh a la otra máquina?


140
2017-07-13 07:44



He copiado la clave privada ssh a la otra máquina como sugirió @Greg. Ahora funciona. ¡Gracias! - Vorleak Chy
Para tu información, puedes usar el indicador -i para señalar la ruta de acceso de las claves sin instalarlas - Jorge Vargas
En mi caso, estaba usando un .ami bitnami y no me di cuenta de que necesita iniciar sesión como usuario llamado bitnami, como: ssh -i <keyfile> bitname@<ec2-address>. Desafortunadamente, el -v La opción no me ayudó a encontrar esto, ¡pero sigue siendo muy útil para verificar! - Matt Connolly
Bueno, en mi caso estaba usando el nombre de usuario incorrecto. estaba usando "ubuntu" en lugar de "bitnami". de esta manera: ssh -i key.pem bitnami @ hostaddress - Lucas Pottersky
Una buena pista también es el nodo remoto en sí mismo, mire /var/log/auth.logA veces verás los siguientes mensajes: Authentication refused: bad ownership or modes for file /var/lib/jenkins/.ssh/authorized_keys o algo mas - Jonas Libbrecht


Como no se ha mencionado explícitamente, sshd es por defecto muy estricto en los permisos para el authorized_keys archivos. Así que si authorized_keys es escribible para cualquier persona que no sea el usuario o se puede hacer escribible por cualquier persona que no sea el usuario, se negará a autenticarse (a menos que sshd esté configurado con StrictModes no)

Lo que quiero decir con "se puede hacer escribible" es que si cualquiera de los directorios principales puede escribirse para cualquier persona que no sea el usuario, los usuarios autorizados para modificar esos directorios pueden comenzar a modificar los permisos de tal manera que puedan modificar / reemplazar authorized_keys.

Esto no se mostrará con ssh -v, se mostrará en los registros emitidos por sshd (que normalmente se colocan en /var/log/secure o /var/log/auth.log, depende de distro y syslogd configuración).

Del hombre sshd (8):

 ~/.ssh/authorized_keys
         Lists the public keys (RSA/DSA) that can be used for logging in
         as this user.  The format of this file is described above.  The
         content of the file is not highly sensitive, but the recommended
         permissions are read/write for the user, and not accessible by
         others.

         If this file, the ~/.ssh directory, or the user's home directory
         are writable by other users, then the file could be modified or
         replaced by unauthorized users.  In this case, sshd will not
         allow it to be used unless the StrictModes option has been set to
         “no”.

73
2018-01-05 14:38



Ese bit "se puede hacer escribible" es lo que me atrapó - wmarbut
FWIW los permisos correctos para los archivos clave son 600 (ver aquí) - Matt Lyons
Sí, mi archivo .authorized_keys se podía escribir por grupo, por lo que se negó a aceptar. - Aditya M P
¡Estaba golpeando mi cabeza contra la pared! Mi carpeta de usuario tenía los permisos equivocados. ¡Gracias! - XJones
Lo mismo ocurre con la carpeta ~ / .ssh en sí. puede obtener el siguiente mensaje de error: Authentication refused: bad ownership or modes for directory - Yevgeniy M.


Recibí este error, porque olvidé agregar -l opción. Mi nombre de usuario local no era el mismo que en el sistema remoto.

Esto no responde a su pregunta, pero llegué aquí buscando una respuesta a mi problema.


37
2018-04-01 21:51



ssh host -l user es lo mismo que ssh user@host, ¿derecho? - Znarkus
@Znarkus sí, es lo mismo. - cregox
Sí, esto resolvió mi problema y causó el error "Permiso denegado (publickey)". - Brooks Moses
Este fue el problema para mí. Esperaba que el usuario "root" funcionara, pero estaba usando una imagen de Ubuntu EC2 que tenía el usuario predeterminado "ubuntu". - Cerin


Recibí este mensaje en una nueva instancia basada en la AMI de Ubuntu. Estaba usando la opción -i para proporcionar el PEM pero aún mostraba el "Permiso denegado (publickey)".

Mi problema fue que no estaba usando el usuario correcto. Al ejecutar ssh con ubuntu @ ec2 ... funcionó de manera normal.


19
2017-11-17 16:29



Sí ... estaba ejecutando el comando con sudo, por lo que no estaba funcionando. - thaddeusmt


Algo que es más fácil de leer que ssh -i (en mi opinión por supuesto), es tail -f /var/log/auth.log. Debe ejecutarse en el servidor al que intenta conectarse, al mismo tiempo que intenta conectarse. Mostrará errores en texto plano.

Esto me ayudó a resolver mi problema:

El usuario [nombre de usuario] de xx.yy.com no está permitido porque ninguno de los grupos de usuarios está listado en AllowGroups


16
2018-02-01 14:07



Creo que quisiste decir -v - Tim Tisdall
este el registro del servidor. para RHEL / CentOS 7: tail -f /var/log/secure - Gianfranco P.


Revisar su / etc / ssh / sshd_config expediente. Allí, encuentra la línea que dice

PasswordAuthentication no

Esa línea necesita ser modificada para decir sí en lugar de no. Además, reinicie el servidor sshd después.

sudo /etc/init.d/ssh restart

11
2017-12-10 06:15



Eso haría que el servidor sea menos seguro. - Znarkus
Este era el problema que tenía: quería configurar una cuenta para otro usuario, autentificando solo con una contraseña. También quería poder iniciar sesión como yo mismo desde lugares donde no tenía mi clave privada. - Daniel
Como podemos ir a /etc/ssh/sshd_config - ¿Si ni siquiera podemos entrar en el servidor? - kyo
Para ingresar al servidor, debe usar el archivo PEM que entregaron cuando creó la instancia. Las instrucciones van después de eso. - Sudipta Chatterjee
Esto funcionó para mí, aunque reiniciar sshd requería el siguiente comando: sudo service sshd reload - pacoverflow


Quizás no sea relevante para el póster actual, pero podría ayudar a otros que lo encuentren al buscar respuestas a situaciones similares. En lugar de permitir que Amazon genere el par de claves ssh, recomiendo que cargue su propia clave ssh pública estándar y predeterminada en Amazon y que especifique eso cuando ejecute una instancia de EC2.

Esto le permite colocar la sintaxis de tipo "-i" en ssh, usar rsync con las opciones estándar y también le permite usar la misma tecla ssh en todas las regiones EC2.

Escribí un artículo sobre este proceso aquí:

Cargar claves ssh personales en Amazon EC2
http://alestic.com/2010/10/ec2-ssh-keys


6
2017-09-29 21:15



+1 Busqué esta pregunta exactamente por esta razón. - John Riselvato
Veo este error al seguir tu artículo. regions = $ (ec2-describe-regions | cut -f2) Opción requerida '-K, falta la clave privada - (-h para el uso) - KashifAli
@KashifAli Querrá configurar las credenciales de la herramienta de línea de comandos de la API de EC2 para que no siempre tenga que pasar las credenciales en cada línea de comandos. - Eric Hammond