publickey - ADVERTENCIA: ¡ARCHIVO DE CLAVE PRIVADO NO PROTEGIDO! al intentar SSH en la instancia de Amazon EC2

permission denied(publickey) aws

Question

Estoy trabajando para configurar Panda en una instancia de Amazon EC2. Anoche configuré mi cuenta y mis herramientas y no tuve problemas para usar SSH para interactuar con mi propia instancia personal, pero ahora mismo no estoy autorizado a ingresar en la instancia de EC2 de Panda. Comenzando con Panda

Me aparece el siguiente error:

@ WARNING: UNPROTECTED PRIVATE KEY FILE! @
Permissions 0644 for ''~/.ec2/id_rsa-gsg-keypair'' are too open.
It is recommended that your private key files are NOT accessible by others.
This private key will be ignored.

He bautizado mi par de llaves a 600 para poder acceder a mi instancia personal anoche, y experimenté largamente configurando los permisos en 0 e incluso generando nuevas cadenas de teclas, pero nada parece estar funcionando.

¡Cualquier ayuda en absoluto sería de gran ayuda!

Hm, parece que a menos que los permisos estén establecidos en 777 en el directorio, el script ec2-run-instances no puede encontrar mis archivos de claves. Soy nuevo en SSH, así que podría estar pasando por alto algo.

Answer 1

He pensado en mi par de llaves a 600 para entrar en mi instancia personal anoche.

Y esta es la forma en que se supone que es.

De la documentación de EC2 tenemos "Si está utilizando OpenSSH (o cualquier cliente SSH razonablemente paranoico), entonces probablemente necesite establecer los permisos de este archivo para que solo usted pueda leerlo". La documentación de Panda que vincula a enlaces a la documentación de Amazon, pero realmente no transmite cuán importante es todo.

La idea es que los archivos de pares de claves sean como contraseñas y necesiten protección. Entonces, el cliente ssh que está utilizando requiere que esos archivos estén seguros y que solo su cuenta pueda leerlos.

Configurar el directorio a 700 realmente debería ser suficiente, pero 777 no va a doler mientras los archivos sean 600.

Cualquier problema que tengas es del lado del cliente, así que asegúrate de incluir la información del sistema operativo local con cualquier pregunta de seguimiento.

Answer 2

Asegúrese de que el directorio que contiene los archivos de la clave privada esté configurado en 700

chmod 700 ~/.ec2

Answer 3

El archivo de clave privada debe estar protegido. En mi caso, he estado usando la autenticación public_key durante mucho tiempo y solía establecer el permiso como 600 (rw --- ---) para clave privada y 644 (rw- r-- r--) y para la carpeta .ssh en la carpeta de inicio tendrá 700 permisos (rwx --- ---). Para configurar esto, vaya a la carpeta de inicio del usuario y ejecute el siguiente comando

Establezca el permiso 700 para la carpeta .ssh

chmod 700 .ssh

Establezca el permiso 600 para el archivo de clave privada

chmod 600 .ssh/id_rsa

Establecer el permiso 644 para el archivo de clave pública

chmod 644 .ssh/id_rsa.pub

Answer 4

Estoy pensando en otra cosa, si intenta iniciar sesión con un nombre de usuario diferente que no existe, este es el mensaje que recibirá.

Así que supongo que es posible que estés intentando chatear con ec2-user pero recuerdo recientemente que la mayoría de los AMI de centos, por ejemplo, están usando centos user en lugar de ec2-user

así que si usted es ssh -i file.pem centos@public_IP por favor dígame que está tratando de obtener el nombre de usuario correcto con ssh, de lo contrario, esta puede ser una fuerte razón para ver ese mensaje de error incluso con los permisos correctos en su ~ / .ssh / id_rsa o file.pem

Answer 5

Mantenga su clave privada, clave pública, known_hosts en el mismo directorio e intente iniciar sesión como se indica a continuación:

ssh -I (pequeño i) "hi.pem" ec2-usuario @ ec2- - - - .us-west-2.compute.amazonaws.com

• El mismo directorio en el sentido, cd / Users / prince / Desktop Ahora escriba el comando ls que debería ver **. Pem **. Ppk known_hosts

Nota: debe intentar iniciar sesión desde el mismo directorio. De lo contrario, obtendrá el error de permiso denegado, ya que no puede tomar el archivo .ppm de su directorio actual.

Answer 6

Para solucionarlo, 1) deberá restablecer los permisos de nuevo a los valores predeterminados:

sudo chmod 600 ~/.ssh/id_rsa sudo chmod 600 ~/.ssh/id_rsa.pub

Si recibe otro error: ¿Está seguro de que desea continuar con la conexión (sí / no)? sí No se pudo agregar el host a la lista de hosts conocidos (/home/geek/.ssh/known_hosts).

2) Esto significa que los permisos en ese archivo también están configurados incorrectamente, y se pueden ajustar con esto:

sudo chmod 644 ~/.ssh/known_hosts

3) Por último, es posible que también deba ajustar los permisos del directorio:

sudo chmod 755 ~/.ssh

Esto debería volver a ponerlo en funcionamiento.

Answer 7

Solo lo hice cuando puse permisos a 400. 600 no lo cortaron.