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:
Establecer permisos correctos para la clave privada . El siguiente comando le ayudará a configurar el permiso de archivo correcto.
chmod 0600 mykey.pem
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 sidoubuntu
.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
Cambiar permiso para el archivo de clave con:
chmod 400 key-file-name.pem
Consulte la documentación de AWS para conectarse a la instancia:
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EC2_GetStarted.html#EC2_ConnectToInstance_Linux
Echa un vistazo a este artículo . No usas el DNS público sino el formulario
ssh -i your.pem [email protected]
donde el nombre es visible en su panel AMI
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
-
ssh-add xyz.pem
-
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
oadmin
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.
- Obtenga su .pem que se generó la primera vez que creó la instancia de EC2.
- Convierta el archivo .pem .ppk usando PuttyGen ya que PuTTY no lee .pem.
- 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.
- 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" .
- 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:
¿Está utilizando el archivo .pem de clave privada correcto?
¿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).
¿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:
Cambiar permisos de la clave.
chmod 400 mykey.pem
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.
- Estás utilizando una clave incorrecta.
- Su clave no tiene los permisos correctos. Necesitas cambiarlo a 400.
- 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
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.