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

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 en este momento no tengo permiso para ingresar a la instancia EC2 de Panda. Comenzando con Panda

Recibo 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.

Cambié mi par de llaves a 600 para poder entrar en mi instancia personal anoche, y experimenté por fin establecer los permisos en 0 e incluso generar nuevas cadenas de teclas, pero parece que nada funciona.

¡Cualquier ayuda 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 clave. Soy nuevo en SSH, así que podría estar pasando por alto algo.

Cambié mi par de llaves a 600 para poder entrar en mi instancia personal anoche,

Y así es como se supone que debe ser.

De la documentación de EC2 tenemos "Si está utilizando OpenSSH (o cualquier cliente SSH razonablemente paranoico), entonces probablemente necesitará 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 lo importante que es todo.

La idea es que los archivos de pares de claves son como contraseñas y deben protegerse. Por lo tanto, el cliente ssh que está utilizando requiere que esos archivos estén protegidos y que solo su cuenta pueda leerlos.

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

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

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

chmod 700 ~/.ec2

Para solucionar esto, 1) deberá restablecer los permisos 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 conectándose (sí / no)? sí Error al 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) Finalmente, es posible que también necesite ajustar los permisos del directorio:

sudo chmod 755 ~/.ssh

Esto debería ayudarlo a volver a funcionar.

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 la 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

Establecer el permiso 700 para la carpeta .ssh

chmod 700 .ssh

Establecer 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

También tuve el mismo problema, pero lo solucioné cambiando el permiso de mi archivo de clave a 600.

sudo chmod 600 /path/to/my/key.pem

Enlace: http://stackabuse.com/how-to-fix-warning-unprotected-private-key-file-on-mac-and-linux/

Mantenga su clave privada, clave pública, conocido_hosts en el mismo directorio e intente iniciar sesión de la siguiente manera:

ssh -I(small i) "hi.pem" ec2-user@ec2-**-***-**-***.us-west-2.compute.amazonaws.com

• Mismo directorio en el sentido, cd /Users/prince/Desktop. Ahora escriba el lscomando y debería ver **.pem **.ppk known_hosts

Nota: Debe intentar iniciar sesión desde el mismo directorio o recibirá un error de permiso denegado ya que no puede encontrar el archivo .pem de su directorio actual.

Si desea poder SSH desde cualquier directorio, puede agregar lo siguiente a su ~/.ssh/configarchivo ...

Host your.server
HostName ec2-user@ec2-**-***-**-***.us-west-2.compute.amazonaws.com
User ec2-user
IdentityFile ~/.ec2/id_rsa-gsg-keypair
IdentitiesOnly yes

Ahora puede enviar SSH a su servidor independientemente de dónde se encuentre el directorio simplemente escribiendo ssh your.server(o el nombre que coloque después de "Host").

En Windows, intente usar git bash y use sus comandos de Linux allí. Enfoque fácil

chmod 400 *****.pem

ssh -i "******.pem" ubuntu@ec2-11-111-111-111.us-east-2.compute.amazonaws.com

Cambiar el permiso de archivo usando el comando chmod

sudo chmod 700 keyfile.pem

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

Así que supongo que puede estar intentando ssh con ec2-user, pero recuerdo recientemente que la mayoría de las AMI de centos, por ejemplo, están usando centos user en lugar de ec2-user

entonces si eres ssh -i file.pem centos@public_IP , dígame que está intentando usar ssh con el nombre de usuario correcto; de lo contrario, esta puede ser una razón importante para que vea dicho mensaje de error incluso con los permisos correctos en su ~ / .ssh / id_rsa o file.pem

Solo una nota para cualquiera que se encuentre con esto:

Si está intentando utilizar SSH con una clave que se ha compartido con usted, por ejemplo:

ssh -i /path/to/keyfile.pem user@some-host

¿Dónde keyfile.pemse comparte la clave privada / pública con usted y la está utilizando para conectarse? Asegúrese de guardarla en ~/.ssh/y chmod 777.

Intentar usar el archivo cuando se guardó en otro lugar en mi máquina estaba dando el error del OP. No estoy seguro si está directamente relacionado.

La solución es hacer que sea legible solo por el propietario del archivo, es decir, los dos últimos dígitos de la representación en modo octal deben ser cero (por ejemplo, modo 0400).

OpenSSH registra esto authfile.c, en una función llamada sshkey_perm_ok:

/*
 * if a key owned by the user is accessed, then we check the
 * permissions of the file. if the key owned by a different user,
 * then we don't care.
 */
if ((st.st_uid == getuid()) && (st.st_mode & 077) != 0) {
    error("@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@");
    error("@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @");
    error("@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@");
    error("Permissions 0%3.3o for '%s' are too open.",
        (u_int)st.st_mode & 0777, filename);
    error("It is required that your private key files are NOT accessible by others.");
    error("This private key will be ignored.");
    return SSH_ERR_KEY_BAD_PERMISSIONS;
}

Vea la primera línea después del comentario: hace un "bit a bit" y contra el modo del archivo, seleccionando todos los bits en los últimos dos dígitos octales (ya que 07es octal para 0b111, donde cada bit representa r ​​/ w / x, respectivamente) .