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

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?

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.

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ó.

Así es como resolví el problema.

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

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

Intenta usar

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

O

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

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

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.

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.

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

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.

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.

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

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".

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 .

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.

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

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.

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.

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

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

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.

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

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).

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)

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ó

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

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.

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.