Cómo solucionar el error "WARNING: UNPROTECTED PRIVATE KEY FILE!" al conectar por SSH con una clave privada a una instancia Linux alojada en Amazon Web Services (AWS) u otro entorno.
Puede pasarnos que al tratar de conectar con una instancia Linux en AWS vía SSH nos aparezca el siguiente mensaje de advertencia en el sistema operativo cliente y no podamos conectarnos:
El problema reside en los permisos del archivo .pem que contiene la clave privada. El sistema no nos deja usarlo si los permisos de lectura / escritura del archivo son demasiado laxos. Con esto, se pretende evitar que otros usuarios puedan copiar una clave privada y usarla sin consentimiento de su propietario.
Para poder usar la clave privada en una conexión SSH, deberemos primero fijar permisos de solo lectura al archivo, y fijarlos solo para el usuario o usuarios que tengan que usar el archivo.
En Linux, deberemos darle permisos 400 o 600 al archivo .pem para poder usarlo:
Alternativamente, si necesitamos que un grupo de usuarios pueda usar la clave privada para iniciar conexiones hacia la instancia, podemos darle permisos "0440" al archivo .pem para que cualquier usuario perteneciente al grupo propietario pueda usar la clave privada.
Si estamos usando OpenSSH en Windows, nos podemos encontrar con el problema inicial, pero al ser Windows, no podremos realizar chmod al archivo. Para modificar los permisos del archivo .pem clicamos el botón derecho del mouse sobre el archivo > Propiedades y otorgamos solamente permisos de Lectura al usuario que va a usar el archivo .pem:
A partir de este momento, independientemente del sistema operativo desde el que trabajemos, ya podremos realizar la conexión hacia la instancia EC2 de turno sin problemas.
Fuentes:
https://stackoverflow.com/questions/9270734/ssh-permissions-are-too-open-error
Puede pasarnos que al tratar de conectar con una instancia Linux en AWS vía SSH nos aparezca el siguiente mensaje de advertencia en el sistema operativo cliente y no podamos conectarnos:
HOST# ssh -i "key.pem" ec2-user@192.168.1.1
The authenticity of host '192.168.1.1' can't be established.
ECDSA key fingerprint is SHA256:fIXn6S2e9d1w3S4LcVXkqyFOWw03M+PrRRq9OqM25BZ.
Are you sure you want to continue connecting (yes/no)? y
Please type 'yes' or 'no': yes
Warning: Permanently added '192.168.1.1' (ECDSA) to the list of known hosts.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: UNPROTECTED PRIVATE KEY FILE! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions for 'key.pem' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "key.pem": bad permissions
ec2-user@192.168.1.1: Permission denied (publickey).
El problema reside en los permisos del archivo .pem que contiene la clave privada. El sistema no nos deja usarlo si los permisos de lectura / escritura del archivo son demasiado laxos. Con esto, se pretende evitar que otros usuarios puedan copiar una clave privada y usarla sin consentimiento de su propietario.
Para poder usar la clave privada en una conexión SSH, deberemos primero fijar permisos de solo lectura al archivo, y fijarlos solo para el usuario o usuarios que tengan que usar el archivo.
En Linux
En Linux, deberemos darle permisos 400 o 600 al archivo .pem para poder usarlo:
HOST# chmod 400 key.pem
Alternativamente, si necesitamos que un grupo de usuarios pueda usar la clave privada para iniciar conexiones hacia la instancia, podemos darle permisos "0440" al archivo .pem para que cualquier usuario perteneciente al grupo propietario pueda usar la clave privada.
En Windows
Si estamos usando OpenSSH en Windows, nos podemos encontrar con el problema inicial, pero al ser Windows, no podremos realizar chmod al archivo. Para modificar los permisos del archivo .pem clicamos el botón derecho del mouse sobre el archivo > Propiedades y otorgamos solamente permisos de Lectura al usuario que va a usar el archivo .pem:
A partir de este momento, independientemente del sistema operativo desde el que trabajemos, ya podremos realizar la conexión hacia la instancia EC2 de turno sin problemas.
Fuentes:
https://stackoverflow.com/questions/9270734/ssh-permissions-are-too-open-error