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

Quiero usar mi instancia de Amazon ec2 pero me encontré con el siguiente error:

Permission denied (publickey). 

Creé mi par de claves y descargué 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 tienes este error:

 Permission denied (publickey) 

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

Este mensaje de error significa que no se pudo autenticar.

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 llaves?
  2. Intentando conectar con el nombre de usuario incorrecto. ubuntu es el nombre de usuario para la distribución AWS basada en ubuntu, pero en algunos otros es ec2-user (o admin en algunos Debians, según la respuesta de Bogdan Kulbida) (también puede ser root , fedora , ver abajo)
  3. Intentando conectar el host equivocado. ¿Es ese el host correcto al que intenta ingresar?

Tenga en cuenta que 1. también ocurrirá si ha estropeado el archivo / /home//.ssh/authorized_keys . /home//.ssh/authorized_keys en su instancia de EC2.

Aproximadamente 2. , la información sobre qué nombre de usuario debe usar a menudo falta en la descripción de AMI Image. Pero puede encontrar algunos en la documentación de AWS EC2, viñeta 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 user_name @ 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, verifique con su proveedor de AMI.

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

En este caso, el problema surge del par de claves perdido. Sobre esto:

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

Puedes seguir estos pasos:

  1. Acceso a la consola de administración de AWS
  2. Pestaña de haba elástica abierta
  3. Seleccione su aplicación desde la pestaña Todas las aplicaciones
  4. Desde el lado izquierdo del menú, selecciona Configuración
  5. Haga clic en el engranaje de instancias
  6. En Formulario de servidor, compruebe la entrada del par de claves EC2 y seleccione su nuevo par de claves. Es posible que deba 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 de EC2. Puedes seguir estos pasos.

  1. Acceso a la consola de administración de AWS
  2. Abra la pestaña EC2
  3. En la lista Instancias, seleccione la instancia que le interese
  4. En la pestaña Descripción, verifique el nombre del grupo de seguridad que está usando su instancia.
  5. De nuevo 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. Si no, en el menú Red y Seguridad, seleccione Grupo de seguridad
  7. Seleccione el grupo de seguridad utilizado por su instancia y haga clic en la pestaña de entrada
  8. A la izquierda de la pestaña de entrada puedes redactar 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. Verifica si ahora puedes conectarte a tu instancia a través de SSH.

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

Así es como resolví el problema

 ssh -i  ec2-user@ 

Resolví el problema simplemente poniendo sudo antes

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

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

 chown wellington:wellington key.pem 

Intenta usar

 sudo ssh -i mykey.pem ubuntu@ 

O

 sudo ssh -i mykey.pem ec2-user@ 

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)

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 

Debes hacer los siguientes pasos:

  1. Abra su cliente o terminal ssh si está usando Linux.
  2. Ubique su archivo de clave privada y cambie su directorio.
    cd
  3. Ejecutar debajo de los comandos:
    chmod 400 .pem
    ssh -i .pem ubuntu@

Si el usuario de ubuntu no funciona, prueba con ec2-user .

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@ -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 de arriba es donde se identificó el problema real; sin embargo, busqué en el mensaje de depuración cuatro líneas desde la parte inferior (arriba) y fui engañado. No hay ningún problema con la clave, pero la probé y comparé otras configuraciones.

Mi archivo de configuración de usuario ssh restablece el host a través de una configuración global involuntaria 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.

Olvidé agregar el nombre de usuario (ubuntu) al conectar mi instancia de Ubuntu. Así que probé 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 

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

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

Aquí hay posibles escenarios frustrantes que producen este error:

Si está almorzando una nueva instancia de una AMI que creó de otra instancia (digamos la instancia xyz), entonces 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 creación de 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.

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

 eb ssh 

Cuando utilizas eso desde el directorio del proyecto, bingo-bango no importa nada, estás en

En mi propio caso, hice lo siguiente:

 chmod 400  ssh -i  ec2-user@ec2_public_dns (for debian) 

Inicialmente estaba usando root@ part y obtuve este mensaje:

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

Estoy en Windows con WinSCP . Funciona muy bien en File Explorer y PuTTY SSH Shell para acceder a mi Amazon EC2-VPC Linux. No hay nada que ver con el chmod pem file ya que usa myfile.ppk convertido por PuTTYgen desde el archivo pem .

Me pasó lo mismo, pero todo lo que sucedía era que la clave privada se había perdido del llavero de mi máquina local.

ssh-add -K

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

Este problema puede resolverse iniciando sesión en el cuadro Ubuntu usando el siguiente comando:

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

He acertado dos veces con las teclas y la línea de comandos de ssh (lo sé porque estoy duplicando una instancia de Ubuntu 14.04 en funcionamiento), pero no he podido acceder a una instancia nueva, incluso después de esperar 5 minutos, como lo sugirió Wade Anderson.

Tuve que destruir y volver a crear la máquina. Esto ha sucedido en dos ocasiones diferentes. Como no puedo entrar al principio, no puedo ver qué pasa.

Entonces, si tienes este problema, inténtalo.

debes verificar estas pocas cosas:

  1. Asegúrese de que su dirección IP sea correcta
  2. Asegúrate de estar usando la clave correcta
  3. Asegúrate de estar usando el nombre de usuario correcto, puedes probar: 3.1. administrador 3.2. ec2-usuario 3.3. ubuntu

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

Mi clave privada se estableció en el permiso 400 y resultó en Permiso denegado configurándolo en ‘644’ me ayudó.

key_load_private_type: El permiso denegado es el error específico que recibí

Solución: Sudo chmod 644

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

Cuando intentas hacer

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

Recibe un mensaje que le aconseja usar el 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

Tuve el mismo problema y es muy extraño. Si crees que estás haciendo todo bien, no sigas esto: ¡algunas veces hay confusión sobre el usuario para la instancia de EC2! Algunas veces obtienes ec2-user, ubuntu, centos, etc. ¡Así que comprueba tu nombre de usuario para el machie !!

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

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

 ssh -i ~/keys/ root@111.111.111.111 

Pero era otro usuario :

 ssh -i ~/keys/ dedeco@111.111.111.111 

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

Para la máquina local, haga esto:

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

Para la máquina remota haz eso:

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

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

Otro posible problema: ID de inicio de sesión incorrecto

Verifique las ‘Instrucciones de uso’

Todas las buenas sugerencias anteriores, pero lo que encontré fue que seleccioné una instancia prefabricada. Después de que la instancia haya comenzado, mira las instrucciones de uso. Incorrectamente utilicé el ID 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)

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 el script de ejecución al iniciar desde el Step 3: Configure instance detail en Advanced 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

Entonces la clave pública en el lado de la instancia no fue creada

Es sensible a mayúsculas y minúsculas

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

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

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

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

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

Lo que salió no coincidía con lo que estaba en ~/.ssh/authorized_keys en la instancia de EC2.

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