virginia refused publickey por permission our instancia ec2 east descargar conectarse conectar change aws acceso amazon-web-services authentication ssh amazon-ec2 permissions

amazon-web-services - publickey - server refused our key aws



Intentando SSH en una instancia de Amazon Ec2-error de permiso (26)

Esta es probablemente una pregunta estúpidamente simple para algunos :)

He creado una nueva instancia de Linux en Amazon EC2 y, como parte de eso, descargué el archivo .pem para permitirme SSH en.

Cuando traté de ssh con:

ssh -i myfile.pem <public dns>

Tengo:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: UNPROTECTED PRIVATE KEY FILE! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ Permissions 0644 for ''amazonec2.pem'' are too open. It is recommended that your private key files are NOT accessible by others. This private key will be ignored. bad permissions: ignore key: amazonec2.pem Permission denied (publickey).

Siguiendo esta publicación intenté hacer chmod +600 el archivo pem, pero ahora cuando ssh solo obtengo:

Permission denied (publickey).

¿Qué error escolar estoy cometiendo aquí? El archivo .pem está en mi carpeta de inicio (en osx). Sus permisos se ven así:

-rw-------@ 1 mattroberts staff 1696 19 Nov 11:20 amazonec2.pem


Además de las otras respuestas, esto es lo que hice para que esto funcione:

  • Copia la clave a la carpeta .ssh si aún no lo has hecho:

cp key.pem ~/.ssh/key.pem

  • Dar los permisos adecuados a la clave.

chmod 400 ~/.ssh/key.pem

  • Inicie ssh-agent (gracias a https://.com/a/17848593 )

eval `ssh-agent -s` ssh-add

  • Luego, agregue la clave

ssh-add ~/.ssh/key.pem

Ahora debería poder ssh EC2 (:


Bueno, mirando la descripción de tu publicación, siento que cometiste 2 errores:

  1. Establecer permisos correctos para la clave privada . El siguiente comando le ayudará a configurar el permiso de archivo correcto.

    chmod 0600 mykey.pem

  2. Usuario EC2 incorrecto que está intentando iniciar sesión .

    Mirando su registro de depuración, creo que ha generado una instancia de Linux linux. El usuario predeterminado para ese tipo de instancia es ec2-user . Si la instancia hubiera sido ubuntu, entonces su usuario predeterminado habría sido ubuntu .

    ssh -i privatekey.pem default_ssh_user@server_ip

Note: For an Amazon Linux AMI, the default user name is ec2-user. For a Centos AMI, the default user name is centos. For a Debian AMI, the default user name is admin or root. For a Fedora AMI, the default user name is ec2-user or fedora. For a RHEL AMI, the default user name is ec2-user or root. For a SUSE AMI, the default user name is ec2-user or root. For an Ubuntu AMI, the default user name is ubuntu. Otherwise, if ec2-user and root don''t work, check with the AMI provider.

fuente: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AccessingInstancesLinux.html




El archivo de claves no debe ser visible públicamente, así que use el permiso 400

chmod 400 keyfile.pem

Si el comando anterior muestra un error de permiso, use

sudo chmod 400 keyfile.pem

Ahora ssh en la máquina ec2, si aún enfrenta el problema, use ec2-user

ssh -i keyfile.pem [email protected]


El problema es tener un mod erróneo en el archivo.

Resuelto fácilmente ejecutando -

chmod 400 mykey.pem

Tomado de las instrucciones de Amazon -

Su archivo de claves no debe ser visible públicamente para que SSH funcione. Use este comando si es necesario: chmod 400 mykey.pem


El problema para mí fue que mi archivo .pem estaba en una de mis particiones NTFS. Lo moví a mi partición de linux (ext4).

Dio los permisos requeridos ejecutando:

chmod 400 my_file.pem

Y funcionó.


En Windows puede ir a las propiedades del archivo pem, ir a la pestaña de seguridad y luego al botón de avance.

Eliminar la herencia y todos los permisos. entonces concédete el control total. después de todo SSL no volverá a dar el mismo error.


En la terminal de Mac, hacer "chmod 400 xyz.pem" no me ayudó, seguía diciendo permiso denegado. Para los usuarios de ubuntu yo sugeriría

  1. ssh-add xyz.pem
  2. ssh -i xyz.pem [email protected] (note que el usuario es ubuntu)

Es probable que estés usando el nombre de usuario incorrecto para iniciar sesión:

  • La mayoría de las imágenes de Ubuntu tienen un usuario de ubuntu
  • AMI de Amazon es ec2-user
  • La mayoría de las imágenes de Debian tienen root o admin

Para iniciar sesión, necesita ajustar su comando ssh:

ssh -l USERNAME_HERE -i .ssh/yourkey.pem public-ec2-host

HTH


Es solo un problema de permiso con la clave aws pem.

Simplemente cambie el permiso de la clave pem a 400 usando el comando a continuación.

chmod 400 pemkeyname.pem

Si no tiene permiso para cambiar el permiso de un archivo, puede usar el comando sudo like below.

sudo chmod 400 pemkeyname.pem

Espero que esto funcione bien.


Este error es solo por el permiso.

Solo dale el permiso 600

#chmod 600 pemfilepath


Haga un chmod 400 yourkeyfile.pem Si su instancia es Amazon linux, use ssh -i yourkeyfile.pem ec2-user @ ip para ubuntu ssh -i yourkeyfile.pem ubuntu @ ip para centos ssh -i yourkeyfile.pem centos @ ip


He visto dos razones detrás de este problema

1) La clave de acceso no tiene el permiso correcto. Las claves pem con permiso predeterminado no están permitidas para realizar una conexión segura. Solo tienes que cambiar el permiso:

chmod 400 xyz.pem

2) También verifique si ha iniciado sesión con las credenciales de usuario adecuadas. De lo contrario, use sudo mientras se conecta.

sudo ssh -i {keyfile} ec2-user @ {dirección ip del host remoto}


Inicio de sesión alternativo utilizando PuTTY. Es bueno pero necesita unos pocos pasos.

  1. Obtenga su .pem que se generó la primera vez que creó la instancia de EC2.
  2. Convierta el archivo .pem .ppk usando PuttyGen ya que PuTTY no lee .pem.
  3. Abra PuTTY e ingrese su Nombre de host, que es su nombre de usuario de instancia + DNS público (por ejemplo, [email protected]). No es el nombre de usuario de su cuenta de AWS.
  4. Luego navegue a Conexión> SSH> Aut . Luego agrega tu archivo .ppk . Haga clic en Examinar donde dice "Archivo de clave privada para autenticación" .
  5. Haga clic en Abrir y debería poder establecer conexión inmediatamente.

Estoy usando PuTTY 0.66 en Windows.


Las claves SSH y las mejores prácticas de permisos de archivos:

  • Directorio .ssh - 0700 (solo por propietario)
  • Archivo de clave privada / .pem - 0400 (solo lectura por propietario)
  • clave pública / archivo .pub - 0600 (solo lectura y escritura por el propietario)

    chmod XXXX file/directory


Lista de verificación:

  1. ¿Está utilizando el archivo .pem de clave privada correcto?

  2. ¿Están sus permisos establecidos correctamente? (Mis AMI de la marca Amazon funcionan con 644, pero Red hat debe tener al menos 600 o 400. No sé sobre Ubuntu).

  3. ¿Está utilizando el nombre de usuario correcto en su línea ssh? Amazon-branded = "ec2-user", Red Hat = "root", Ubuntu = "ubuntu". El usuario puede especificarse como "ssh -i pem usename @ hostname" O "ssh -l nombre de usuario -i pem hostname"


Lo que solucionó esto fue mover el archivo .pem dentro del directorio de aplicaciones. Soo say fooapp es el nombre de mi aplicación. Lo coloqué directamente allí.


Los siguientes son los pasos simples para que el usuario de Linux se conecte con el servidor utilizando el archivo .pem:

Paso 1: a la ubicación del archivo pem y cópielo en la ubicación .ssh de inicio.

cp example.pem ~/.ssh/example.pem

Paso 2: Cambiar el permiso

chmod 400 ~/.ssh/example.pem

Paso 3: Ejecuta el siguiente comando

ssh -i ~/.ssh/example.pem [email protected]

Como este comando es demasiado largo, debe crear el alias de este con los siguientes comandos:

vim ~/.bashrc

Escribe el mismo comando de la siguiente manera en la última.

alias sshConnect=''ssh -i ~/.ssh/example.pem [email protected]''

Ahora reinicie su sistema y use sshConnect para conectarse con su servidor.


Ok hombre, lo único que me funcionó fue:

  1. Cambiar permisos de la clave.

    chmod 400 mykey.pem

  2. Asegúrese de iniciar sesión con ec2-user y la dirección ec2-99 ... correcta. La dirección ec2-99 está en la parte inferior de la consola aws cuando inicia sesión y ve su instancia en la lista

    ssh -i mykey.pem [email protected]


Por defecto los permisos no permiten la clave pem. Solo tienes que cambiar el permiso:

chmod 400 xyz.pem

y si la instancia de ubuntu entonces conecta usando:

ssh -i xyz.pem [email protected]


Puede haber tres razones detrás de este error.

  1. Estás utilizando una clave incorrecta.
  2. Su clave no tiene los permisos correctos. Necesitas cambiarlo a 400.
  3. Estás utilizando al usuario incorrecto. Las imágenes de Ubuntu tienen un usuario ubuntu , la AMI de Amazon es ec2-user y las imágenes de Debian tienen root o admin

Sé que esta pregunta ya ha sido respondida, pero para aquellos que los han probado todos y usted todavía está recibiendo el molesto "Permiso denegado (publickey)". Intenta ejecutar tu comando con SUDO. Por supuesto, esta es una solución temporal y debe establecer los permisos correctamente, pero al menos eso le permitirá identificar que su usuario actual no se está ejecutando con los privilegios que necesita (como asumió)

sudo ssh -i amazonec2.pem ec2-xxx-xxx-xxx-xxx.us-west-2.compute.amazonaws.com

Una vez que hagas esto recibirás un mensaje como este:

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

Que también está escasamente documentado. En ese caso solo haz esto:

sudo ssh -i amazonec2.pem ec2-xxx-xxx-xxx-xxx.us-west-2.compute.amazonaws.com -l ec2-user

Y obtendrás lo glorioso

__| __|_ ) _| ( / Amazon Linux AMI ___|/___|___|


Sé que esto es muy tarde para el juego ... pero esto siempre funciona para mí:

paso 1

ssh-add ~/.ssh/KEY_PAIR_NAME.pem

paso 2, simplemente ssh en :)

ssh user_name@<instance public dns/ip>

p.ej

ssh [email protected]

Espero que esto ayude a alguien.


Simplemente cambie el permiso del archivo pem a 0600 permitiendo solo al usuario permitido y funcionará a la perfección.

sudo chmod 0600 myfile.pem

Y luego tratar de ssh funcionará perfectamente.

ssh -i myfile.pem <<ssh_user>>@<<server>>


ssh -i /.pem usuario @ host-machine-IP

Creo que es porque ha ingresado credenciales incorrectas o bien, está utilizando una clave pública en lugar de una clave privada o sus permisos de puerto están abiertos para que TODOS lo hagan por ssh. Esto es malo para Amazon.