amazon web services - refused - AWS ssh access ''Permiso denegado(publickey)'' problema

permission denied publickey gssapi keyex gssapi with mic aws

Question

¿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 dijo a la API de AWS que usara este par de llaves y guardó el par de llaves en el archivo:

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

5. Comenzó una instancia de AWS Ubuntu 9 usando este par de llaves:

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

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

   $ ssh -v -i ec2-keypair.pem [email protected]
   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 hacerlo funcionar?

Answer 1

Ahora es:

ssh -v -i ec2-keypair.pem ec2-user@[yourdnsaddress]

Answer 2

El permiso para ec2-keypair.pem debe ser 400

chmod 400 ec2-keypair.pem

Answer 3

En mi caso (Mac OS X), el problema fue el tipo de ruptura 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)".

Answer 4

Hay 2 pasos para estar conectados:

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, necesita conocer la dirección IP pública de su instancia:

ssh -i toto.pem [email protected]

Espero eso ayude !

Answer 5

Las versiones de Canonical usan el usuario ''ubuntu'' de manera predeterminada para cualquiera que aterrice aquí con una imagen de ubuntu que presente el mismo problema.

Answer 6

Necesitas tener tu clave privada en tu máquina local.

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

Si eres usuario de Linux

• Asegúrese de que los permisos de la clave privada sean 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 usuario de windows

• Use PuTTy para crear la sesión ssh ( http://the.earth.li/~sgtatham/putty/latest/x86/putty-0.66-installer.exe )
• Si su archivo de clave privada está en formato .pem, conviértalo a .ppk usando puttygen
• Ejecute PuTTy, establezca su archivo ppk, dirección IP o nombre DNS del servidor remoto e inicie la sesión ssh

Answer 7

Para instancias de Ubuntu:

chmod 600 ec2-keypair.pem
ssh -v -i ec2-keypair.pem [email protected]

Para otros casos, es posible que tenga que usar ec2-user lugar de ubuntu .

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

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

Answer 8

Para las instancias de Debian EC2, el usuario es admin .

Answer 9

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

Answer 10

Sólo añadiendo a esta lista. Tuve problemas esta mañana con un nuevo usuario que se agregó a una instancia de AWS EC2. Para reducir el problema, el problema era selinux (que estaba en modo de cumplimiento ), 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 descifrarlo, ya que revisé todos los demás problemas habituales de ssh (/ etc / ssh / sshd_config estaba bien, por supuesto, no se permiten contraseñas, los permisos son correctos, etc.)

¿La solución?

Por ahora (hasta que comprendo cómo permitir que un usuario acceda a un volumen diferente, o de alguna manera convertir ese volumen en un punto dir 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.

Answer 11

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

mira mi debug y mira la ultima:

*

ssh -v -i awsliferaysrta.pem.txt [email protected].***
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 [email protected]
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".

*

Answer 12

Si está utilizando EBS, también puede intentar montar el volumen de EBS en una instancia en ejecución. Luego, instálalo en esa instancia en ejecución y mira qué está pasando en / home. Puedes ver cosas como es el usuario ubuntu o ec2-user? o tiene las claves públicas correctas en ~ / .ssh / authorized_keys

Answer 13

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

Parece obvio, pero algo que pasé por alto.

Answer 14

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

Answer 15

También me estaba encontrando con esto - resulta que estaba usando una AMI creada por la comunidad - y el nombre de usuario predeterminado era niehter root, ni era ect-user o ubuntu. De hecho, no tenía ni idea de lo que era, hasta que probé '' root '' y el servidor me pidió amablemente que ingresara como xxx, donde xxx es lo que sea que te diga.

-¡aclamaciones!

Answer 16

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

Answer 17

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

Buscó 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 correcta en la página wiki de Debian.

Espero que esto ayude.

Answer 18

Ubuntu 10.04 con openSSH

Este es el uso exacto:

ssh -v -i [yourkeypairfile] ec2-user@[yourdnsaddress]

por ejemplo:

ssh -v -i GSG_Keypair.pem [email protected]

el ejemplo anterior se tomó directamente del tutorial de AWS para conectarse a una máquina Linux / UNIX en: http://docs.amazonwebservices.com/AWSEC2/latest/GettingStartedGuide/

Answer 19

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 otra vez 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-usuario

No tuve que volver a crear la instancia desde una imagen.

Answer 20

utilizar...

# chmod 400 ec2-keypair.pem

no utilice el permiso 600, de lo contrario podría sobrescribir su clave de forma accidental.