publickey por permission instancia ec2 descargar conectar change aws acceso amazon-web-services ssh amazon-ec2

amazon-web-services - por - permission denied(publickey). ssh aws ec2



Permiso denegado(publickey) cuando el acceso SSH a la instancia de Amazon EC2 (29)

Aquí hay unos posibles escenarios frustrantes que producen este error:

Si está almorzando una nueva instancia de una AMI que creó de otra instancia (por ejemplo, instancia xyz), entonces la nueva instancia solo aceptará la misma clave que la instancia A usó. Esto es totalmente comprensible, pero se vuelve confuso porque durante el proceso paso a paso de crear la nueva instancia, se le solicita 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 usando, por ejemplo, XYZ.

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

Permission denied (publickey).

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

Dado:

chmod 600 pem file.

Entonces, este comando

ssh -i /home/kashif/serverkey.pem [email protected]

Pero ten este error:

Permission denied (publickey)

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

Así resolví el problema.

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

Cuando intentas hacer

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

ec2-user un mensaje que te aconseja utilizar el ec2-user .

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

Asi que usa

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

Debes comprobar estas pocas cosas:

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

Tuve el mismo problema, y ​​se 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í.

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

  • No hay manera de cambiar el par de claves en una instancia . Tienes que crear una nueva instancia que utiliza 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. Lengüeta Elástica Abierta Abierta
  3. Seleccione su aplicación de la pestaña Todas las aplicaciones
  4. Desde el lado izquierdo, seleccione la configuración.
  5. Haga clic en el engranaje de instancias
  6. En forma de servidor, verifique 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 ti nuevas instancias asociadas con el nuevo par de claves.

En general, recuerde que debe permitir que su instancia de 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. Abrir la pestaña EC2
  3. Desde la lista de instancias, seleccione la instancia que le interesa
  4. En la pestaña Descripción, verifique el nombre del grupo de seguridad que usa 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 Menús de 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 puede redactar una regla para el tráfico de entrada de SSH:
    • Crear 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 en Aplicar 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ó.

En mi caso, hice lo siguiente:

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

Inicialmente estaba usando root@ part y obtuve este indicador:

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

Es sensible a las mayúsculas.

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

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

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

ssh -i ~/keys/<key_name> [email protected]

Pero era otro usuario :

ssh -i ~/keys/<key_name> [email protected]

Este mensaje de error significa que no se pudo autenticar.

Estas son razones comunes que pueden causar que:

  1. Tratando de conectar con la clave incorrecta. ¿Estás seguro de que esta instancia está utilizando este par de llaves?
  2. Tratando de conectar con el nombre de usuario incorrecto. ubuntu es el nombre de usuario para la distribución de 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 más abajo)
  3. Tratando de conectar el host incorrecto. ¿Es el host correcto al que está intentando iniciar sesión?

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

Acerca de 2. , la información sobre el nombre de usuario que debe usar a menudo no se encuentra en 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

Utilice 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, consulte con su proveedor de AMI.

Finalmente , tenga en cuenta que hay muchas otras razones por las que la autenticación fallaría. Por lo general, SSH es 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.

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

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

Esto me ha pasado muchas veces. He utilizado 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, tengo permiso denegado para aparecer. No he verificado esto, pero mi teoría es que el servidor no está completamente configurado antes de intentar insertarlo. Después de algunos intentos con permiso denegado, espero unos minutos y luego puedo conectarme. Si tiene este problema, le sugiero que espere cinco minutos y vuelva a intentarlo.

Estoy en Windows con WinSCP . Funciona muy bien tanto en el Explorador de archivos como en PuTTY SSH Shell para acceder a mi Amazon EC2-VPC Linux. No hay nada que ver con el chmod pem file ya que utiliza myfile.ppk converted por PuTTYgen desde el archivo pem .

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

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

Entonces, si tienes este problema, inténtalo.

Intenta usar

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

O

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

Lo mismo me pasó a mí, pero todo lo que estaba sucediendo es que la llave 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.

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''

La salida 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 un problema con la clave, pero la probé y comparé otras configuraciones.

El archivo de configuración de mi usuario ssh restablece 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 lo encuentre útil.

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

eb ssh

Cuando lo usas en el directorio del proyecto, bingo-bango no muss sin alboroto, estás en

Mi clave privada se configuró en el permiso 400 y resultó en un permiso denegado, lo que me ayudó a ''644''.

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

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

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

Necesitas hacer los siguientes pasos:

  1. Abra su cliente o terminal ssh si está usando 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 usuario de ubuntu no funciona, intente con ec2-user .

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

Otra posible causa de este error:

Cuando el directorio de inicio del usuario se puede escribir en grupo , el usuario no puede iniciar sesión.

(Reproducido en instancia de Ubuntu.)

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

Consulte las ''Instrucciones de uso''

Todas las buenas sugerencias anteriores, pero me topé con que seleccioné una instancia prefabricada. Una vez iniciada la instancia, mire las instrucciones de uso. Usé incorrectamente 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 @ dominio -i clave.pem)

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

La forma en que me di cuenta de esto fue obteniendo la clave pública de mi clave privada, como esta:

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

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

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 dijo a continuación. En mi caso sería:

chown wellington:wellington key.pem

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

Tuve el mismo error pero situación diferente. Para mí, sucedió de la nada después de mucho tiempo, pude ssh con éxito a mi computadora remota. Después de mucho buscar la solución a mi problema fueron los permisos de archivos. Por supuesto, es extraño porque no cambié ningún permiso en mi computadora o en el remoto que pertenece a los archivos / directorios de ssh. Así que desde el wiki de Archlinux bueno 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 trabajar de nuevo sin el permiso denegado (publickey).

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

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

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 en el inicio del Step 3: Configure instance detail en Advanced details:

Lo que pensé entré:

#include https://xxxx/bootstrap.sh

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

#include

https://xxxx/bootstrap.sh

Así que la clave pública en el lado de la instancia no fue creada

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