El mensaje
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: UNPROTECTED PRIVATE KEY FILE! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/home/user/.ssh/id_ed25519' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "/home/user/.ssh/id_ed25519": bad permissions
user@server: Permission denied (publickey,password).A pesar de la palabra "warning", esto impide que se use la clave. La comprobación ocurre en tu propio ordenador, antes de usar la clave privada para firmar nada. El servidor no te ha rechazado.
La solución
chmod 600 ~/.ssh/id_ed25519Usa la ruta que muestra el mensaje. El modo 600 significa que solo tú puedes leer y escribir. El modo 400, solo lectura, también se acepta. Cualquier permiso para el grupo o para otros se rechaza: probamos 640, 660, 644 y 440, y los cuatro dieron este error.
Para comprobarlo sin conectarte, usa uno de estos:
ls -l ~/.ssh/id_ed25519
ssh-keygen -y -f ~/.ssh/id_ed25519El segundo comando imprime la clave pública si los permisos están bien, y el mismo aviso si no lo están. Si la clave tiene una frase de contraseña, la pide antes.
Para ordenar toda una carpeta:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_*
chmod 644 ~/.ssh/*.pubLas claves públicas pueden seguir siendo legibles, por eso la última línea las restaura.
Cómo acaba una clave con estos permisos
- Se copió desde una memoria USB, una carpeta compartida o un archivo zip, o se descargó desde un navegador.
- Un script o la restauración de una copia de seguridad la escribió con el modo por defecto.
- Alguien ejecutó
chmod -R 755sobre el directorio personal.
Si no sabes por dónde ha pasado una clave copiada, es más sencillo generar una nueva clave SSH Ed25519 y sustituir la antigua en tus servidores.
Casos relacionados en tu ordenador
La clave pertenece a otro usuario
Una clave creada con sudo pertenece a root. Con el modo 600 no puedes leerla en absoluto, y el mensaje es distinto:
Load key "/home/user/.ssh/id_ed25519": Permission deniedRecupérala con sudo chown "$USER" ~/.ssh/id_ed25519.
Sin aviso, solo Permission denied
Si hay un archivo .pub junto a la clave, ssh ofrece primero la mitad pública y solo lee el archivo privado cuando el servidor la acepta. Así que con una clave equivocada nunca ves este aviso, aunque los permisos sean malos. ssh -v muestra el orden:
debug1: Offering public key: /home/user/.ssh/id_ed25519 ED25519 SHA256:...
debug1: Server accepts key: /home/user/.ssh/id_ed25519 ED25519 SHA256:...
Permissions 0644 for '/home/user/.ssh/id_ed25519' are too open.El archivo de configuración
El mismo tipo de comprobación se aplica a la configuración de tu cliente:
Bad owner or permissions on /home/user/.ssh/configArréglalo con chmod 600 ~/.ssh/config.
Windows
OpenSSH en Windows usa listas de control de acceso a archivos, no chmod. Estos comandos de PowerShell vienen de la documentación de AWS, con la ruta de tu clave en $path:
icacls.exe $path /reset
icacls.exe $path /GRANT:R "$($env:USERNAME):(R)"
icacls.exe $path /inheritance:rEn WSL, una clave bajo /mnt/c puede no conservar los permisos de Linux. Cópiala a ~/.ssh dentro del sistema de archivos de Linux y ejecuta allí chmod 600.
El mismo problema en el servidor: StrictModes
El servidor tiene una comprobación parecida, pero no ves ningún aviso. El cliente solo imprime Permission denied (publickey,password). y el motivo está en el registro del servidor, que necesitas leer por otra vía, como una consola:
Authentication refused: bad ownership or modes for directory /home/user/.sshEn Debian y Ubuntu usa sudo journalctl -u ssh, y en la mayoría de los demás sistemas journalctl -u sshd. Esto es lo que vimos con OpenSSH 10.0 de Debian 13, con StrictModes yes, el valor por defecto:
| Cambio | Resultado |
|---|---|
Directorio personal 777 | Rechazado, bad ownership or modes for directory |
~/.ssh con escritura para el grupo, el grupo es root | Rechazado, el mismo mensaje |
authorized_keys con escritura para el grupo, el grupo es root | Rechazado, bad ownership or modes for file |
authorized_keys propiedad de root, modo 600 | Rechazado, Could not open user 'user' authorized keys |
authorized_keys modo 644 | El acceso funciona |
~/.ssh modo 755 | El acceso funciona |
La compilación de Debian también permitió la escritura para el grupo cuando el grupo era el grupo privado del propio usuario, así que no esperes lo mismo en todos los sistemas. El ajuste seguro es el mismo en todas partes. Ejecuta esto como el usuario en el servidor:
chmod go-w ~
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R "$USER" ~/.sshSi ejecutas la última línea con sudo, escribe el nombre del usuario en lugar de $USER.
No pongas StrictModes no. Hace que el acceso funcione, como confirmamos, pero también acepta un archivo authorized_keys que otros usuarios pueden haber podido modificar. Para ver el valor actual:
sudo sshd -T | grep -i strictmodesSi los modos son correctos y la clave sigue rechazándose, mira Permission denied (publickey).
Preguntas
¿Qué permisos debe tener una clave privada SSH?
600, para que solo tú puedas leerla y escribirla. 400, solo lectura, también sirve. Cualquier acceso para el grupo u otros hace que ssh ignore la clave.
¿Qué permisos deben tener ~/.ssh y authorized_keys?
700 para ~/.ssh y 600 para authorized_keys. Las claves públicas que terminan en .pub pueden quedarse en 644.
¿Se puede desactivar la comprobación de permisos?
En el cliente, no. En el servidor, StrictModes no se salta su comprobación, pero también acepta un authorized_keys que otros podrían haber cambiado, así que corrige los permisos.
Fuentes
- ssh(1), manual de OpenBSD
- sshd_config(5), StrictModes
- Troubleshoot connecting to an EC2 Linux instance, AWS