sent - permission denied(publickey). ssh aws ec2

Amazon EC2 Permiso denegado(publickey) (12)

Esto parece ser un problema común, pero mi caso específico parece un poco diferente.

Configuré una nueva instancia de Amazon EC2 usando las herramientas de línea de comandos y me conecté a través de SSH e hice algunos trabajos de configuración.

Inicialmente, sin embargo, no pude ingresar a la instancia, tuve que detenerme y reiniciar la instancia, entonces pude conectarme. Antes de reiniciar, recibí la respuesta.

Permission denied (publickey).

Eso fue anoche, esta mañana vuelvo a la misma instancia y ahora todo lo que tengo es

Permission denied (publickey).

Intenté reiniciar la instancia sin alegría.

Puede alguien señalarme la dirección correcta? El mismo comando que funcionó anoche ya no funciona, me estoy conectando desde mi Macbook Pro.

¡Gracias!

Realmente aprecio la respuesta de Trevor aquí. Voy a agregar este pequeño truco que ahora uso para evitar este problema en el futuro.

Conveniencia

Debido a que tiene que crear un par de claves diferente para cada zona de disponibilidad, se convierte en un gran problema administrarlos todos y los comandos que los utilizan. Con la configuración adecuada en ~/.ssh/config mi comando ssh es tan simple como:

ssh ec2-52-10-20-30.us-west-2.compute.amazonaws.com

Ese es el DNS público completo de un servidor en la zona de disponibilidad Oeste de los EE. UU. El nombre de usuario y la clave apropiados se seleccionan debido a esto:

## ~/.ssh/config Host *.us-west-2.compute.amazonaws.com User ec2-user IdentityFile ~/.ssh/bruno-bronosky-aws-us-west-2.pem

Asegúrese de que la ruta a su clave privada sea correcta.

Si su cliente ssh no puede encontrar la clave privada que está tratando de proporcionar, ¡por extraño que parezca, no le dará un error! simplemente no usará esa clave. Utilizará cualquier clave que tenga bajo .ssh / id_dsa y .ssh / id_ecdsa que, por supuesto, debilitará la autenticación de clave pública.

Cambié los permisos a 600, aunque los permisos en el archivo pem ya eran 644. Y eso funcionó: p espero que ayude

Esto estaba sucediendo para mí porque no estaba usando el nombre de usuario correcto. Pude iniciar sesión cuando uso un AMI utilizado en un tutorial que estaba siguiendo, pero cuando traté de usar un AMI diferente (ubuntu + LAMP de Bitnami) obtenía el Permission denied (public key). error. Finalmente me di cuenta de que si cambiaba el nombre de usuario del tutorial ami de ubuntu a ec2-user , obtendría el mismo error.

Entonces, un google rápido dice que el nombre de usuario de Bitnami AMIs es bitnami . Problema resuelto.

Lo resolví copiando el contenido de ~ / .ssh / id_rsa.pub a ~ / .ssh / authorized_keys en la instancia de EC2.

Esto se especifica en la documentación: http://docs.aws.amazon.com/opsworks/latest/userguide/security-ssh-access.html

Entonces podría ssh usando este comando:

ssh ec2-user@[ip.address]

Me encontré con un problema similar y resultó ser permisos en la carpeta de inicio. Afortunadamente, todavía tenía abierta otra conexión ssh existente, así que pude verificar el registro en la instancia de ec2:

$ sudo menos / var / log / secure

que contenía:

Dec 9 05:58:20 ... sshd[29816]: Authentication refused: bad ownership or modes for directory /home/ec2-user

Esto se solucionó al emitir el comando:

$ chmod og-rwx / home / ec2-usuario

Espero que esto ayude a alguien más.

Pasé todo el día buscando en internet la respuesta. Mi problema es exactamente el mismo. Jugueteé con el tema del permiso, cambié de un lado a otro, pero ninguno resolvió mi problema. Después de probar con una nueva clave y comenzar / terminar un par de instancias, finalmente encontré que tiene que ver con el mismo nombre de clave en diferentes regiones.

Así es como me pasó "Permiso denegado (publickey)":
1. Siga el libro de práctica, seleccione el us-east-1 como zona predeterminada
2. Crea un nombre de clave "mykey"
3. Explorando el mundo AWS siguiendo los ejemplos en ese libro.
4. Un día, intente probar las velocidades de la zona de Sydney, cambie a Sydney Zone como predeterminado.
5. Crea otra clave, llámala "mykey" sin pensar, pero no la uses para conectarte a través de cli por un par de días.
6. Intente conectarse a AWS usando cli.
7. Obtuve "Permiso denegado (publickey)".
8. Pasé muchas horas para solucionar el problema de ssh hasta que noté el problema de la tecla / zona.

Espero que esto pueda ayudar a un novato como yo.

Para evitar este problema, creo que la mejor práctica para nombrar una clave es adjuntar una región.

Si la instancia EC2 usa Ubuntu ami 14.04. Intente agregar ''ubuntu @'' antes de la instancia de IP ip.

ssh -i [key name] ubuntu@[EC2 instance ip]

También recibí: Permiso denegado.

Solía :

ssh -v -i ~/.ssh/pemfile [email protected]

y la respuesta fue:

debug1: No more authentication methods to try.

Ingrese el comando:

ssh-add -l

Pero la respuesta fue vacía

Por lo tanto, creo que el archivo de lápiz tiene algo incorrecto sobre el formato. A continuación, encontré el archivo de lápiz descargado de la web ec2 y lo moví de nuevo. Antes de esto, creé un nuevo archivo y analicé el texto del archivo pem descargado en el directorio ".ssh", luego:

ssh-add filename

Que fue exitoso

Tenga en cuenta que después de reiniciar la instancia, el nombre dns cambió. Me enamoré de esto varias veces. El archivo de claves todavía era válido, pero el "nombre de servidor" cambió.

Tuve el mismo problema, esto es lo que debes hacer. En primer lugar, si tiene Windows, use la línea de comando de Babun, que es como la de Linux. Una vez que tenga esa línea de comando, ábrala y escriba ssh-i [key pair path] [username]@[EC2 public IP]. Para encontrar la ruta del par de claves, vaya al archivo donde está almacenada su clave, mantenga presionada la tecla Mayús y haga clic con el botón derecho y haga clic en copiar ruta, y péguelo donde va la ruta en el comando anterior. Probablemente obtendrá "" marcas en el exterior de la ruta que pegó, y / barras diagonales inversas. Elimine las marcas "" y reemplace las / barras diagonales con barras regulares /. Esto funcionó en una situación como esta, tuve la mejor de las suertes.

Voy a responder mi propia pregunta en caso de que alguien más vea lo mismo ... Anoche había hecho:

ssh-add ~/.ssh/[keypair name]

luego me he estado conectando con:

ssh ec2-user@[ec2 instance ip]

Esta mañana probé lo mismo y no pude conectarme. Pero haciendo

ssh -i ~/.ssh/[keypair name] ec2-user@[ec2 instance ip]

me hace entrar

El uso de ssh-add en el par de claves me lleva de nuevo. Supongo que ssh-add solo funciona dentro del shell en el que lo emití. Cuando cerré la ventana del terminal y abrí otro, ya no tuve ese par de claves disponible sin ser explícito.