Acceso a AWS ssh 'Permiso denegado (clave pública)' problema [cerrado]

284

¿Cómo conectarse a una instancia de AWS a través de ssh?

Yo tengo:

  1. Registrado en AWS;
  2. Creé una clave pública y un certificado en el sitio web de AWS y los guardé en el disco;

  3. Fui a mi consola y creé variables de entorno: 

    $ export JAVA_HOME=/usr/lib/jvm/java-6-openjdk/
$ export EC2_CERT=/home/default/aws/cert-EBAINCRNWHDSCWWIHSOKON2YWGJZ5LSQ.pem
$ export EC2_PRIVATE_KEY=/home/default/aws/pk-EBAINCRNWHDSCWWIHSOKON2YWGJZ5LSQ.pem

  4. Le dije a AWS API que usara este par de claves y lo guardó en el archivo: 

    $ ec2-add-keypair ec2-keypair > ec2-keypair.pem

  5. Comencé una instancia de AWS Ubuntu 9 usando este par de claves: 

    $ ec2-run-instances ami-ed46a784 -k ec2-keypair

  6. Intentó establecer una conexión ssh con la instancia: 

    $ ssh -v -i ec2-keypair.pem ubuntu@ec2-174-129-185-190.compute-1.amazonaws.com
OpenSSH_5.1p1 Debian-5ubuntu1, OpenSSL 0.9.8g 19 Oct 2007
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to ec2-174-129-185-190.compute-1.amazonaws.com [174.129.185.190] port 22.
debug1: Connection established.
debug1: identity file ec2-keypair.pem type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1p1 Debian-5ubuntu1
debug1: match: OpenSSH_5.1p1 Debian-5ubuntu1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.1p1 Debian-5ubuntu1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'ec2-174-129-185-190.compute-1.amazonaws.com' is known and matches the RSA host key.
debug1: Found key in /home/default/.ssh/known_hosts:11
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: ec2-keypair.pem
debug1: read PEM private key done: type RSA
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
Permission denied (publickey).

    ¿Cuál podría ser el problema y cómo hacer que funcione?

amazon-web-services  ssh-keys 
— Alex
fuente
2
Irónico es que uso "root" como nombre de usuario, pero "ubuntu" (lo que mencionaste) es el nombre correcto para mi AMI, ¡y gracias por tu publicación!
— realjin
— CtheGood

Respuestas:

512

Para instancias de Ubuntu:

chmod 600 ec2-keypair.pem
ssh -v -i ec2-keypair.pem ubuntu@ec2-174-129-185-190.compute-1.amazonaws.com

Para otros casos, puede que tenga que usar en ec2-userlugar de ubuntu.

La mayoría de las imágenes de Linux EC2 que he usado solo tienen el usuario root creado de forma predeterminada.

Ver también: http://www.youtube.com/watch?v=WBro0TEAd7g

— sipwiz
fuente
66
¡Tú Molas! ¡Tan simple!
— Alex
50
También puede usar ssh-add-EC2 keypair.pem lo que puede caer la opción -i
— adamk
12
si prueba root y obtiene "Inicie sesión como usuario ec2-user en lugar de usuario root". use ec2-user en lugar de root.
— Tony
8
Y algunas imágenes de Ubuntu parecen tener solo el usuario "ubuntu". (Que puede sudo a la raíz.)
— contrato del Prof. Falken incumplió el
1
Super, super útil.
— NSCoder
93

Ahora es:

ssh -v -i ec2-keypair.pem ec2-user@[yourdnsaddress]
— SSH
fuente
Gracias. Me llevó mucho tiempo descubrir esto: ¡no se menciona en la información de conexión de la consola! Te dice cuándo intentas usar root, pero pensé que ec2-user era una referencia a mi nombre de usuario. Doh!
— Adrian Mouat
1
Oh hombre. No es un dato fácil de encontrar. ¡Gracias!
— vroomfondel
gracias, no es fácil encontrar este
¡Muy bien! ¡Gracias!
— viana
46

Los lanzamientos de Canonical usan el usuario 'ubuntu' por defecto para cualquier persona que aterrice aquí con una imagen de ubuntu que tenga el mismo problema.

— Bryon
fuente
2
No es fácil encontrarlo.
— Gustav
17

Si está utilizando una imagen de Bitnami, inicie sesión como 'bitnami'.

Parece obvio, pero algo que pasé por alto.

— akim
fuente
Su respuesta me salvó el día!
— Surya
2
¿Querías decir? Seems <sarcasm>obvious</sarcasm>
— Bob Stein
Instrucciones de Bitnami , incluido cómo encontrar las contraseñas de la base de datos.
— Bob Stein
8

Para mis imágenes de ubuntu, en realidad es usuario de ubuntu y NO el usuario de ec2;)

— Dean Hiller
fuente
5

También se quejará si los permisos del archivo pem son demasiado abiertos. chmod el archivo a 600 para arreglar eso.

— Allan Bogh
fuente
Gracias por este consejo - me ayudó mucho
— Billy Moon
44
Para los principiantes ... el comando para hacer esto sería:chmod 600 your_file.pem
— dano
5

También me encontré con esto, resulta que estaba usando un AMI creado por la comunidad, y el nombre de usuario predeterminado era niehter root, ni ect-user ni ubuntu. De hecho, no tenía idea de qué era, hasta que probé ' root ' y el servidor me pidió amablemente que iniciara sesión como xxx, donde xxx es lo que te dice.

-¡salud!

— kevinfoundananswwer
fuente
4

Necesita tener su clave privada en su máquina local

Debe conocer la dirección IP o el nombre DNS de su máquina o servidor remoto, puede obtenerlo desde la consola de AWS

Si eres un usuario de Linux

  • Asegúrese de que los permisos en la clave privada son 600 ( chmod 600 <path to private key file>)
  • Conéctese a su máquina usando ssh ( ssh -i <path to private key file> <user>@<IP address or DNS name of remote server>)

Si eres un usuario de Windows

— Vineeth Guna
fuente
Cambie el permiso del archivo usando chmod 400 <clave pem>
— Vaibhav Jain
3

utilizar... 

# chmod 400 ec2-keypair.pem

no use el permiso 600; de lo contrario, podría sobrescribir su clave accidentalmente.

— x1b2j
fuente
2

esto funcionó para mí:

ssh-keygen -R <server_IP>

para eliminar las claves antiguas almacenadas en la estación de trabajo también funciona en lugar de

luego haciendo el mismo ssh nuevamente funcionó:

ssh -v -i <your_pem_file> ubuntu@<server_IP>

en instancias de ubuntu el nombre de usuario es: ubuntu en Amazon Linux AMI el nombre de usuario es: ec2-user

No tuve que volver a crear la instancia a partir de una imagen.

— Cris
fuente
2

Hay 2 pasos para conectarse:

Chmod 400 en su clave privada, así los demás no pueden acceder a su clave:

chmod 400 toto.pem

Para conectarse a su instancia en SSH, debe conocer la dirección IP pública de su instancia: 

ssh -i toto.pem ec2-user@XX.XX.XX.XXX

Espero eso ayude !

— GuillaumeAgis
fuente
1

Si está utilizando EBS, también puede intentar montar el Volumen EBS en una instancia en ejecución. Luego móntelo en esa instancia en ejecución y vea lo que sucede en / home. Puedes ver cosas como ¿es el usuario ubuntu o ec2-user? o tiene las claves públicas correctas en ~ / .ssh / Authorizedkeke

— Rico
fuente
1

El permiso para ec2-keypair.pemdebe ser400

chmod 400 ec2-keypair.pem

— Yogui
fuente
1

Si está ejecutando la imagen de AWS desde Bitnami. El nombre de usuario sería bitnami. ¡Salud!

mira mi depuración y mira la última:

* *

ssh -v -i awsliferaysrta.pem.txt root@54.254.250.***
OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: Connecting to 54.254.250.*** [54.254.250.***] port 22.
debug1: Connection established.
debug1: identity file awsliferaysrta.pem.txt type -1
debug1: identity file awsliferaysrta.pem.txt-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1 Debian-5ubuntu1.1
debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1.1 pat OpenSSH_5*
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA 05:5c:78:45:c9:39:3a:84:fe:f8:19:5d:31:48:aa:5f
debug1: Host '54.254.250.***' is known and matches the RSA host key.
debug1: Found key in /Users/macbookpro/.ssh/known_hosts:2
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: awsliferaysrta.pem.txt
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
Authenticated to 54.254.250.*** ([54.254.250.***]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: Remote: Port forwarding disabled.
debug1: Remote: Agent forwarding disabled.
debug1: Remote: X11 forwarding disabled.
debug1: Remote: Forced command.
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
Please login as the user "bitnami" rather than the user "root".

* *

— Hung Do
fuente
1

En mi caso (Mac OS X), el problema era el tipo de interrupción del archivo. Prueba esto:

1.- Abra el archivo .pem con TextWrangler

2.- En la parte inferior de la aplicación, verifique si el Tipo de interrupción es "Windows (CRLF)".

— pmartinezd
fuente
1

Su usuario ec2 para Amazon Linux AMI y ubuntu para imágenes de Ubuntu. Además, RHEL 6.4 y posterior ec2-user RHEL 6.3 y anterior root Fedora ec2-user Centos root

— Amith Ajith
fuente
0

Solo agregando a esta lista. Esta mañana tuve problemas con un nuevo usuario recién agregado a una instancia de AWS EC2. Para ir al grano, el problema era selinux (que era hacer cumplir modo ), junto con el hecho de que mi directorio de inicio de usuario estaba en un nuevo volumen adjunto de EBS. De alguna manera, supongo que a selinux no le gusta ese otro volumen. Me tomó un tiempo darme cuenta, mientras revisaba todos los otros problemas habituales de ssh (/ etc / ssh / sshd_config estaba bien, por supuesto, no se permitía contraseña, los permisos eran correctos, etc.)

¿La solución?

Por ahora (hasta que entienda cómo permitir que un usuario ssh a un volumen diferente, o de alguna manera hacer que ese volumen sea un punto de inicio de buena fe):

sudo perl -pi -e 's/^SELINUX=enforcing/SELINUX=permissive/' /etc/selinux/config
sudo setenforce 0

Eso es. Ahora mi nuevo usuario puede iniciar sesión, utilizando su propia clave id_rsa.

— Pierre D
fuente
0

Tuve el mismo problema. Permiso denegado (publickey) al intentar iniciar sesión con 'ec2-user' o con 'root'.

Busqué en Google el número AMI de la imagen de la máquina y tenía la información de inicio de sesión SSH directamente en la página wiki de Debian.

Espero que esto ayude.

— Lionel Morrison
fuente
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.