AWS acceso ssh 'Permiso denegado (clavepublica)' tema [cerrado]
-
12-09-2019 - |
Pregunta
Cómo conectarse a una instancia de AWS a través de ssh?
Tengo:
- Se inscribió en AWS;
- Crea una clave pública y del certificado en el sitio web de AWS y se guarda en el disco;
Fui a mi consola y crea las 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
Dicho de AWS, API para el uso de este par de claves y salvó el par de claves en el archivo:
$ ec2-add-keypair ec2-keypair > ec2-keypair.pem
Comenzó AWS Ubuntu 9 ejemplo el uso de este par de claves:
$ ec2-run-instances ami-ed46a784 -k ec2-keypair
Trató de establecer una conexión ssh a 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?
Solución
Para los casos de Ubuntu:
chmod 600 ec2-keypair.pem
ssh -v -i ec2-keypair.pem ubuntu@ec2-174-129-185-190.compute-1.amazonaws.com
En otros casos, puede que tenga que utilizar ec2-user
en lugar de ubuntu
.
Las imágenes más EC2 Linux que he usado sólo tienen el usuario root creado por defecto.
Vea también: http://www.youtube.com/watch?v=WBro0TEAd7g
Otros consejos
Ahora es:
ssh -v -i ec2-keypair.pem ec2-user@[yourdnsaddress]
comunicados de Canonical utilizan los usuarios 'ubuntu' por defecto para cualquier persona aterrizar aquí una imagen de Ubuntu que viene con el mismo problema con.
Si está utilizando una imagen de Bitnami, entre como 'bitnami'.
Parece obvio, pero algo que se pasa por alto.
En mis imágenes ubuntu, en realidad es usuario de Ubuntu y NO el EC2-usuario;)
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 ec2-user@ec2-184-72-204-112.compute-1.amazonaws.com
ejemplo anterior fue tomada directamente de la tutorial AWS para la conexión a una máquina Linux / UNIX en: http://docs.amazonwebservices.com/AWSEC2/latest/GettingStartedGuide/
También se quejan de que los permisos PEM son demasiado abierta. chmod el archivo a 600 de arreglar eso.
También estaba corriendo en esto - resulta que estaba usando un IAM creado por la comunidad - y el nombre de usuario por defecto era la raíz niehter, ni tampoco era ect-usuario o ubuntu. De hecho, no tenía ni idea de lo que era - hasta que probé ' root ' y el servidor amablemente me pidió que iniciar la sesión como xxx en xxx es lo que le dice.
-cheers!
Usted necesita tener su clave privada en su máquina local
Es necesario conocer la dirección IP o el nombre DNS de la máquina o servidor remoto, puede obtener esta información de la consola AWS
Si usted es un usuario de Linux
- Asegúrese de que los permisos de la clave privada son 600
(
chmod 600 <path to private key file>
) - Conectar a la máquina mediante ssh
(
ssh -i <path to private key file> <user>@<IP address or DNS name of remote server>
)
Si usted es un usuario de Windows
- Utilice masilla para crear la sesión ssh ( http : //the.earth.li/~sgtatham/putty/latest/x86/putty-0.66-installer.exe)
- Si el archivo de clave privada está en formato .pem convertirlo en .PKK usando puttygen
- Lanzamiento de masilla, conjunto que PPK archivo, la dirección IP o el nombre DNS del servidor remoto e inicie la sesión ssh
El uso ...
# chmod 400 ec2-keypair.pem
No utilice el permiso 600 de lo contrario podría sobrescribir accidentalmente su clave.
Esto funcionó para mí:
ssh-keygen -R <server_IP>
para eliminar las viejas claves almacenadas en la estación de trabajo También funciona con en lugar de
a continuación, hacer lo mismo otra vez ssh funcionó:
ssh -v -i <your_pem_file> ubuntu@<server_IP>
en casos ubuntu el nombre de usuario es: ubuntu en Amazon Linux AMI es el nombre de usuario: EC2-usuario
Yo no tenía que volver a crear la instancia de una imagen.
Para instancias de EC2 Debian, el usuario es admin
.
Si está utilizando EBS, también se puede tratar de montar el volumen EBS en una instancia en ejecución. A continuación, montarlo en esa instancia en ejecución y ver lo que está pasando en / home. Se puede ver cosas como es el ubuntu usuario o EC2-usuario? o tiene las claves públicas correctas en ~ / .ssh / authorized_keys
El permiso para ec2-keypair.pem
debe 400
chmod 400 ec2-keypair.pem
Si está ejecutando desde la imagen de AWS Bitnami. El nombre de usuario sería bitnami. Saludos!
ver a mi depurar y mirar a 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".
*
Hay 2 pasos para ser conectado:
Chmod 400 con su clave privada, como este que los otros no pueden tener acceso a su clave:
chmod 400 toto.pem
Para conectarse a la instancia en SSH, usted necesita saber la dirección IP pública de tu ejemplo :
ssh -i toto.pem ec2-user@XX.XX.XX.XXX
Espero que ayude !
En mi caso (Mac OS X), el problema era de tipo ruptura del archivo. Prueba esto:
1.- Abrir el archivo .pem con TextWrangler
2.- En la parte inferior de la aplicación, verificar si el tipo de rotura es "Windows (CRLF)".
Su EC2-usuario para Amazon Linux AMI de imágenes y Ubuntu para Ubuntu. Además, RHEL 6.4 y más tarde por el usuario EC2 RHEL 6.3 y la raíz anterior Fedora EC2-usuario centos raíz
Simplemente añadiendo a esta lista. Yo estaba teniendo problemas esta mañana con un nuevo usuario se agregó a una instancia AWS EC2. Para ir al grano, el problema era SELinux (que estaba en Cómo hacer valer los modo), junto con el hecho de que mi directorio home del usuario estaba en un nuevo volumen EBS adjuntos. De alguna manera creo que SELinux no le gusta que otro volumen. Me tomó un tiempo para averiguar, al mirar a través de todos los demás temas habituales (ssh / etc / ssh / sshd_config estaba bien, por supuesto, ninguna contraseña permitidos, permisos estaban en lo cierto, etc.)
La solución?
Por ahora (hasta que entienda cómo permitir a un usuario ssh a un volumen diferente, o de alguna manera hacer que el volumen de un punto a casa de buena fe dir):
sudo perl -pi -e 's/^SELINUX=enforcing/SELINUX=permissive/' /etc/selinux/config
sudo setenforce 0
Eso es todo. Ahora mi nuevo usuario puede iniciar sesión, usando su propia clave id_rsa.
tenían el mismo problema. Permiso denegado (publickey) al intentar iniciar sesión con 'EC2-usuario' o con 'root'.
buscado en Google el número IAM de la imagen de la máquina y que tenía la información de inicio de sesión SSH derecha de su página en la wiki de Debian.
Espero que esto ayude.