Permiso denegado (clave pública) cuando el acceso SSH a la instancia de Amazon EC2 [cerrado]


355

Quiero usar mi instancia de Amazon ec2 pero me enfrenté al siguiente error:

Permission denied (publickey).

He creado mi par de claves y he descargado el archivo .pem .

Dado:

chmod  600 pem file.

Entonces, este comando

ssh -i /home/kashif/serverkey.pem  ubuntu@ec2-54-227-242-179.compute-1.amazonaws.com

Pero ten este error:

Permission denied (publickey)

Además, ¿cómo puedo conectarme con Filezilla para cargar / descargar archivos?


1
con respecto a su segunda pregunta, conéctese con filezilla para cargar / descargar archivos, consulte esto para obtener instrucciones paso a paso - y2u.be/e9BDvg42-JI
Yasitha Chinthaka

2
¿está seguro de que no usó "sudo chmod 600 pem file"? Esto causaría este error y significaría que necesitaría usar sudo antes de ssh
felbus

También para algunos SO Debian el nombre de usuario es admin. Al menos para las versiones 6.5 y 7.0.
Desarrollador

2
Si su nombre de usuario es ec2-user, asegúrese de no estar usando ec2_user:)
grisaitis

2
Asegúrese de que el usuario al que está intentando conectarse tenga la clave en su $HOME/.ssh/authorized_keys archivo.
ILMostro_7

Respuestas:


589

Este mensaje de error significa que no pudo autenticarse.

Estas son razones comunes que pueden causar eso:

  1. Intentando conectar con la clave incorrecta. ¿Estás seguro de que esta instancia está usando este par de claves?
  2. Intentando conectar con el nombre de usuario incorrecto. ubuntues el nombre de usuario para la distribución de AWS basado ubuntu, pero en algunos otros es ec2-user(o adminen algunos Debians, de acuerdo con la respuesta de Bogdan Kulbida) (también puede ser root, fedora, ver más abajo)
  3. Intentando conectar el host incorrecto. ¿Es ese el host correcto en el que estás intentando iniciar sesión?

Tenga en cuenta que 1.también sucederá si ha desordenado el /home/<username>/.ssh/authorized_keysarchivo en su instancia EC2.

Acerca de 2., la información sobre qué nombre de usuario debe usar a menudo carece de la descripción de la imagen AMI. Pero puede encontrar algunos en la documentación de AWS EC2, punto 4.: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AccessingInstancesLinux.html

Use el comando ssh para conectarse a la instancia. Especificará el archivo de clave privada (.pem) y el nombre de usuario @ public_dns_name. Para Amazon Linux, el nombre de usuario es ec2-user. Para RHEL5, el nombre de usuario es root o ec2-user . Para Ubuntu, el nombre de usuario es ubuntu . Para Fedora, el nombre de usuario es fedora o ec2-user . Para SUSE Linux, el nombre de usuario es root . De lo contrario, si ec2-user y root no funcionan, consulte con su proveedor de AMI.

Finalmente , tenga en cuenta que hay muchas otras razones por las cuales la autenticación podría fallar. SSH generalmente es bastante explícito sobre lo que salió mal si le importa agregar la -vopción a su comando SSH y leer el resultado, como se explica en muchas otras respuestas a esta pregunta.


2
No creo que la interfaz le ofrezca agregar una clave a una instancia en ejecución, por lo que tendrá que iniciar una nueva si ha perdido la clave en su instancia en ejecución.
Thibault D.

81
# 2 solucionó mi problema, ¡gracias!
rckehoe

44
Esta respuesta lo resolvió para mí. El nombre de usuario predeterminado para esta instancia era "ubuntu", no ec2-user como se dice en el manual de AWS. Intente usar'ec2-user@_your_EC2_IP.amazonaws.com
emf

77
Con respecto al n. ° 1, la clave incorrecta, agregar -v (detallado) a la línea de comando ssh me mostró qué claves estaba intentando y eso me llevó a darme cuenta de que no estaba probando la clave que había generado porque la había llamado algo más que id_rsa o id_dsa.
KC Baltz

3
"ubuntu es el nombre de usuario para la distribución de AWS basada en ubuntu," Esto es lo que me atrapó. Estaba acostumbrado a ec2-user, simplemente asumí que siempre era el nombre de usuario.
Nate Reed

48

En este caso, el problema surge de la pérdida del par de claves. Sobre esto:

  • No hay forma de cambiar el par de claves en una instancia . Debe crear una nueva instancia que use un nuevo par de claves.
  • Puede solucionar el problema si su aplicación es utilizada por Elastic Beanstalk .

Puedes seguir estos pasos:

  1. El acceso a los consola de administración de AWS
  2. Frijoles elásticos abiertos pestaña
  3. Seleccione su aplicación desde Todas las aplicaciones pestaña
  4. Desde el menú del lado izquierdo, seleccione Configuración
  5. Haga clic en el engranaje de instancias
  6. En el formulario del servidor, verifique la entrada del par de claves EC2 y seleccione su nuevo par de claves. Puede que tenga que actualizar la lista para ver un nuevo par de claves que acaba de crear.
  7. Salvar
  8. Elastic Beanstalk creará para usted nuevas instancias asociadas con el nuevo par de claves.

En general, recuerde que debe permitir que su instancia EC2 acepte el tráfico SSH entrante.

Para hacer esto, debe crear una regla específica para el Grupo de seguridad de su instancia EC2. Puedes seguir estos pasos.

  1. Acceso a la consola de administración de AWS
  2. Abrir pestaña EC2
  3. De la lista de instancias, seleccione la instancia que le interesa
  4. En la pestaña Descripción, marque el nombre del grupo de seguridad que usa su instancia.
  5. Nuevamente en la pestaña Descripción, haga clic en Ver reglas y verifique si su Grupo de seguridad tiene una regla para el tráfico ssh entrante en el puerto 22
  6. De lo contrario, en el menú Red y seguridad, seleccione Grupo de seguridad
  7. Seleccione el grupo de seguridad utilizado por su instancia y haga clic en pestaña Entrante
  8. A la izquierda de la pestaña Inbound puede componer una regla para el tráfico entrante SSH:
    • Crea una nueva regla : SSH
    • Fuente : dirección IP o subred desde la que desea acceder a la instancia
    • Nota : Si desea otorgar acceso ilimitado a su instancia, puede especificar 0.0.0.0/0 , aunque Amazon no recomienda esta práctica
  9. Haga clic en Agregar regla y luego aplique sus cambios
  10. Compruebe si ahora puede conectarse a su instancia a través de SSH.

Espero que esto pueda ayudar a alguien como me ayudó.


1
La segunda parte de tu respuesta es incorrecta. No puede obtener el "Permiso denegado (clave pública)". si no ha configurado correctamente la configuración del firewall (Grupos de seguridad). "Permiso denegado (clave pública)". es un mensaje de error de SSH y es una prueba de que la configuración de los grupos de seguridad es correcta. En su lugar, obtendría "ssh: conectarse al puerto xxxx del host 22: conexión rechazada"
Thibault D.

Larga historia corta: el mensaje de error dice que este problema no tiene nada que ver con la configuración de los grupos de seguridad.
Thibault D.

Tienes razón. La segunda parte trata otro tipo de problema. Arreglé la publicación.
Matteo Ceserani

Si perdió la clave, creo que una posible forma de resolverlo sería tomar una instantánea de la instancia y luego comenzar una nueva con una nueva clave. En ese caso, Amazon agrega la nueva clave pública en .ssh / Authorized_keys, así que asegúrese de eliminar la anterior después. (y tenga cuidado de no eliminar el nuevo o volverá a su primer problema)
Thibault D.

43

Así es como resolví el problema.

ssh -i <key> ec2-user@<ec2 ip>

1
Parecía que la clave para mí aquí era la dirección DNS del host vs IP. ec2-user @ <ip> funcionó para mí.
Zack

1
Solución también.
Tpojka

26

Resolví el problema solo poniendo sudoantes

sudo ssh -i mykey.pem myec2.amazonaws.com

Pero la solución adecuada es cambiar primero la propiedad y luego conectarse como un usuario normal como Janus Troelsen dijo a continuación. En mi caso sería:

chown wellington:wellington key.pem

¡Me funcionó (aunque tuve que actualizar algunos paquetes después)!
user1429980

44
la solución adecuada es cambiar primero la propiedad y luego conectarse como un usuario normal. uso sudo chown wellington:wellington key.pem.
Janus Troelsen

está funcionando, en su caso porque está intentando iniciar sesión en esa VM en Amazon que admite el usuario root
Taimoor Changaiz

Hice whoami y luego sudo chown user_name_given_by_whoami xxxx.pem
Chirag Purohit el

23

Intenta usar

sudo ssh -i mykey.pem ubuntu@<ec2_ip_public_dns>

O

sudo ssh -i mykey.pem ec2-user@<ec2_ip_public_dns>

1
Esto me ayudo. ¡Gracias por el consejo! : D
jehzlau

22

Otra posible causa de este error:

Cuando el directorio de inicio del usuario es de escritura grupal , el usuario no puede iniciar sesión.

(Reproducido en la instancia de Ubuntu).


1
¡¡¡Ojalá hubiera leído esto hace 4 horas !!! Solucioné mi problema donde rsync -a sobrescribía el permiso de mi carpeta ec2-user.
Michael Hobbs

Después de mover mi directorio de inicio, no pude iniciar sesión.
Robert Moon

Entonces, ¿cómo inicia sesión en una máquina que se ve afectada y no puede iniciar sesión en absoluto?
PKHunter

Los permisos fijos en el directorio / home también funcionan para mí, ¡gracias! @AlexPetralia, su enlace está roto = / pero tiene una publicación en el foro aws que habla de esto: forums.aws.amazon.com/message.jspa?messageID=334402
Liko

¿Puede alguien como Alex Petralia o @Michael Hobbs volver a publicar (o reformular) la solución a esto?
Jakub Langr

7

para la instancia micro de ubuntu 12.04 lts tuve que configurar el nombre de usuario como opción

ssh -i pemfile.pem -l ubuntu dns

esto funcionó para mí, me sorprende que no sea parte de la documentación de aws discutir realmente sobre los usuarios que pueden ser necesarios.
Ben

7

Debe seguir los siguientes pasos:

  1. Abra su cliente o terminal ssh si está utilizando Linux.
  2. Localice su archivo de clave privada y cambie su directorio.
    cd <path to your .pem file>
  3. Ejecute los siguientes comandos:
    chmod 400 <filename>.pem
    ssh -i <filename>.pem ubuntu@<ipaddress.com>

Si el ubuntuusuario no está trabajando, intente con ec2-user.


5

Luché con el mismo permiso denegado error aparentemente debido a

key_parse_private2: missing begin marker 

En mi situación, la causa fue el archivo de configuración ssh del usuario actual (~ / .ssh / config).

Usando lo siguiente:

ssh -i ~/myKey.pem ec2-user@<IP address> -v 'exit'

El resultado inicial mostró:

debug1: Reading configuration data /home/ec2-user/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 56: Applying options for *
debug1: Hostname has changed; re-reading configuration
debug1: Reading configuration data /home/ec2-user/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config

... muchas líneas de depuración cortadas aquí ...

debug1: Next authentication method: publickey
debug1: Trying private key: /home/ec2-user/somekey.pem
debug1: key_parse_private2: missing begin marker
debug1: read PEM private key done: type RSA
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.

La tercera línea anterior es donde se identificó el problema real; sin embargo, busqué el mensaje de depuración a cuatro líneas de la parte inferior (arriba) y me equivoqué. No hay ningún problema con la clave, pero la probé y comparé otras configuraciones.

Mi archivo de configuración ssh de usuario restableció el host a través de una configuración global no deseada como se muestra a continuación. La primera línea de host no debería haber sido un comentario.

$ cat config
StrictHostKeyChecking=no
#Host myAlias
        user ec2-user
        Hostname bitbucket.org
#        IdentityFile ~/.ssh/somekey
#        IdentitiesOnly yes

Host my2ndAlias
        user myOtherUser
        Hostname bitbucket.org
        IdentityFile ~/.ssh/my2ndKey
        IdentitiesOnly yes

Espero que alguien más encuentre esto útil.


4

Olvidé agregar el nombre de usuario (ubuntu) al conectar mi instancia de Ubuntu. Entonces intenté esto:

ssh -i /path/my-key-pair.pem my-ec2-instance.amazonaws.com

y la forma correcta era

ssh -i /path/my-key-pair.pem ubuntu@my-ec2-instance.amazonaws.com

Error de principiante legítimo. Si olvida agregar el nombre de usuario, utilizará el nombre de usuario del usuario con el que inició sesión en su computadora local.
Thibault D.

3

Esto me ha pasado varias veces. He usado Amazon Linux AMI 2013.09.2 y Ubuntu Server 12.04.3 LTS que están en el nivel gratuito.

Cada vez que lanzo una instancia, se me niega el permiso para aparecer. No he verificado esto, pero mi teoría es que el servidor no está completamente configurado antes de intentar ingresar en él. Después de algunos intentos con el permiso denegado, espero unos minutos y luego puedo conectarme. Si tiene este problema, le sugiero que espere cinco minutos y vuelva a intentarlo.


Esperé 5 minutos. Y funcionó. Estoy en el nivel libre también. gracias
Emeka Mbah

2

Aquí hay posibles escenarios frustrantes que producen este error:

Si está almorzando una nueva instancia de un AMI que creó de otra instancia (por ejemplo, instancia xyz), la nueva instancia solo aceptará la misma clave que la instancia A utilizada. Esto es totalmente comprensible, pero se vuelve confuso porque durante el proceso paso a paso de crear la nueva instancia, se le pide que seleccione o cree una clave (en el último paso) que no funcionará.

Independientemente de la clave que cree o seleccione, la nueva instancia solo aceptará la clave que estaba utilizando, por ejemplo, XYZ.


Wow, nunca he pensado en esto. El uso de la clave anterior resolvió el problema para mí. Gracias.
tolgamorf

Por lo general, agrega la nueva clave pública al archivo Authorized_keys, por lo tanto, ambos son utilizables. Sin embargo, ha pasado un tiempo desde que lo probé, pero eso es lo que esperaría que sucediera.
Thibault D.

2

Luché con esto por un tiempo también hasta que encontré lo siguiente:

eb ssh

Cuando usas eso desde el directorio del proyecto, bingo-bango no muss no fuss, estás en


2

En mi propio caso, hice lo siguiente:

chmod 400 <key.pem>

ssh -i <key.pem> ec2-user@ec2_public_dns (for debian)

Inicialmente estaba usando root@parte y recibí este mensaje:

Please login as the user "ec2-user" rather than the user "root".

2

Estoy en Windows con WinSCP . Funciona muy bien tanto en File Explorer como en PuTTY SSH Shell para acceder a mi Amazon EC2-VPC Linux. No hay nada que ver chmod pem fileya que utiliza myfile.ppk convertidos por PuTTYgen desde el archivo pem .


2

Me pasó lo mismo, pero todo lo que estaba sucediendo es que la clave privada se perdió del llavero en mi máquina local.

ssh-add -K

volvió a agregar la clave, luego el comando ssh para conectarse volvió a funcionar.


Sucede cada vez que se reinicia y necesito volver a ejecutar el comando anterior para solucionarlo.
silentsudo

1
no he verificado esto yo mismo, pero la respuesta verificada aquí podría ayudar: apple.stackexchange.com/questions/254468/…
eiTan LaVi

1

Este problema se puede resolver iniciando sesión en el cuadro de Ubuntu usando el siguiente comando:

ssh -i ec2key.pem ubuntu@ec2-public-IP

1
Por favor, dar algunos detalles.
Syeda Zunaira

1

Dos veces tuve claves y línea de comando ssh correcta (lo sé porque estoy duplicando una instancia de Ubuntu 14.04 que funciona), pero simplemente no pude ingresar a una nueva instancia, incluso después de esperar 5 minutos como sugirió Wade Anderson anteriormente.

Tuve que destruir y recrear la máquina. Esto ha sucedido en dos ocasiones separadas. Como no puedo entrar inicialmente, no puedo ver qué pasa.

Entonces, si tienes este problema, pruébalo.


1

debes verificar estas pocas cosas:

  1. Asegúrese de que su dirección IP sea correcta
  2. Asegúrese de estar usando la clave correcta
  3. Asegúrese de estar usando el nombre de usuario correcto, puede intentar: 3.1. admin 3.2. usuario ec2 3.3. ubuntu

Tuve el mismo problema y se resolvió después de cambiar el nombre de usuario a ubuntu. En AWS, se mencionó la documentación al usuario ec2-user, pero de alguna manera no me funciona.


1

Mi clave privada se configuró con permiso 400y resultó en Permiso denegado. Establecerlo en '644' me ayudó.

key_load_private_type: Permiso denegado es el error específico que estaba recibiendo

Solución: Sudo chmod 644 <key.pem>

Nota: establecido en 644 es obligatorio, no funcionaba con 400


1

Cuando intentas hacer

ssh -i <.pem path> root@ec2-public-dns

Recibes un mensaje que te aconseja usar ec2-user.

Please login as the user "ec2-user" rather than the user "root".

Entonces usa

ssh -i <.pem path> ec2-user@ec2-public-dns


1

Tuve el mismo problema y es muy extraño. Si cree que está haciendo todo lo bueno, siga esto: ¡Algunas veces hay confusión sobre el usuario para la instancia EC2! Algunas veces obtienes ec2-user, ubuntu, centos, etc. ¡¡Comprueba tu nombre de usuario para el machie !!

Inicie sesión con el usuario root ssh -i yourkey.pem (400 permission) root@<ip> Lanzará un error y le dará el nombre de usuario disponible . luego inicie sesión con ese usuario.


1

Es algo básico, pero siempre confirma qué usuario estás intentando iniciar sesión. Soy mi caso fue solo una distracción . Estaba intentando usar un usuario root :

ssh -i ~/keys/<key_name> root@111.111.111.111

Pero fue otro usuario :

ssh -i ~/keys/<key_name> dedeco@111.111.111.111

1

Tuve el mismo error pero diferente situación. para mí sucedió de la nada después de mucho tiempo que pude enviar con éxito a mi computadora remota. Después de mucho buscar la solución a mi problema fueron los permisos de archivo. es extraño, por supuesto, porque no cambié ningún permiso en mi computadora o en el remoto que pertenece a los archivos / directorios de ssh. así que del buen archlinux wiki aquí está:

Para la máquina local, haga esto:

$ chmod 700 ~/
$ chmod 700 ~/.ssh
$ chmod 600 ~/.ssh/id_ecdsa

Para la máquina remota, haga eso:

$ chmod 700 ~/
$ chmod 700 ~/.ssh
$ chmod 600 ~/.ssh/authorized_keys

después de eso, mi ssh comenzó a funcionar nuevamente sin el permiso denegado (publickey).


0

Otro problema posible: identificación de inicio de sesión incorrecta

Verifique las 'Instrucciones de uso'

Todas las buenas sugerencias anteriores, pero me encontré con que seleccioné una instancia prefabricada. Después de que la instancia ha comenzado, mira las instrucciones de uso. Utilicé incorrectamente la identificación de inicio de sesión de la clave privada cuando en las instrucciones se suponía que debía usar 'bitnami' (por ejemplo, bitnami @ domain -i key.pem)


0

Tuve un error similar

debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: xxxx.pem
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
Permission denied (publickey).

Mi problema fue que la instancia no se inició correctamente debido a un error en la secuencia de comandos de ejecución inicial desde Step 3: Configure instance detailabajoAdvanced details:

Lo que pensé que entré:

#include
 https://xxxx/bootstrap.sh


Lo que realmente ingresó rompe la configuración de la instancia

#include

https://xxxx/bootstrap.sh

Por lo tanto, la clave pública en el lado de la instancia no se creó


0

Es sensible a mayúsculas y minúsculas.

Incorrecto: SSH EC2-usuario @ XXX.XX.XX.XX -i MyEC2KeyPair.pem

Correcto: SSH ec2-user @ XXX.XX.XX.XX -i MyEC2KeyPair.pem


-1

Pude SSH desde una máquina, pero no desde otra. Resulta que estaba usando la clave privada incorrecta.

La forma en que descubrí esto fue obteniendo la clave pública de mi clave privada, así:

ssh-keygen -y -f ./myprivatekey.pem

Lo que salió no coincidió con lo que había en ~/.ssh/authorized_keysla instancia EC2.


-1

Todas las respuestas mejor clasificadas arriba son precisas y deberían funcionar para la mayoría de los casos. En el caso de que no lo hicieran como en mi caso, simplemente me deshice de mi ~/.ssh/known_hostsarchivo en la máquina de la que estaba tratando de hacer ssh y eso resolvió el problema para mí. Pude conectarme después.


Si bien la eliminación known_hostspuede resolver un problema al conectarse al servidor que ha cambiado su clave de host (aunque de todos modos es un mal enfoque), estoy bastante seguro de que no puede resolver el error "Permiso denegado (clave pública)" .
Martin Prikryl
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.