Il messaggio
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ 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).Nonostante la parola "warning", questo impedisce l'uso della chiave. Il controllo avviene sul tuo computer, prima che la chiave privata venga usata per firmare qualsiasi cosa. Il server non ti ha rifiutato.
La soluzione
chmod 600 ~/.ssh/id_ed25519Usa il percorso mostrato nel messaggio. Il modo 600 significa che solo tu puoi leggere e scrivere. Viene accettato anche il modo 400, sola lettura. Qualsiasi permesso per il gruppo o per gli altri viene rifiutato: abbiamo provato 640, 660, 644 e 440 e tutti e quattro hanno dato questo errore.
Per controllare senza collegarti, usa uno di questi:
ls -l ~/.ssh/id_ed25519
ssh-keygen -y -f ~/.ssh/id_ed25519Il secondo comando stampa la chiave pubblica se i permessi sono a posto, e lo stesso avviso se non lo sono. Se la chiave ha una passphrase, la chiede prima.
Per sistemare un'intera cartella:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_*
chmod 644 ~/.ssh/*.pubLe chiavi pubbliche possono restare leggibili, ed è per questo che l'ultima riga le ripristina.
Come una chiave finisce con questi permessi
- È stata copiata da una chiavetta USB, da una cartella condivisa o da un file zip, oppure scaricata da un browser.
- Uno script o il ripristino di un backup l'ha scritta con il modo predefinito.
- Qualcuno ha eseguito
chmod -R 755sulla directory home.
Se non sai dove è passata una chiave copiata, è più semplice generare una nuova chiave SSH Ed25519 e sostituire quella vecchia sui tuoi server.
Casi collegati sul tuo computer
La chiave appartiene a qualcun altro
Una chiave creata con sudo appartiene a root. Con il modo 600 non puoi leggerla affatto, e il messaggio è diverso:
Load key "/home/user/.ssh/id_ed25519": Permission deniedRiprendila con sudo chown "$USER" ~/.ssh/id_ed25519.
Nessun avviso, solo Permission denied
Se accanto alla chiave c'è un file .pub, ssh offre prima la metà pubblica e legge il file privato solo quando il server la accetta. Quindi con una chiave sbagliata non vedi mai questo avviso, anche con permessi errati. ssh -v mostra l'ordine:
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.Il file di configurazione
Lo stesso tipo di controllo vale per la configurazione del tuo client:
Bad owner or permissions on /home/user/.ssh/configCorreggilo con chmod 600 ~/.ssh/config.
Windows
OpenSSH su Windows usa le liste di controllo di accesso dei file, non chmod. Questi comandi PowerShell vengono dalla documentazione di AWS, con il percorso della tua chiave in $path:
icacls.exe $path /reset
icacls.exe $path /GRANT:R "$($env:USERNAME):(R)"
icacls.exe $path /inheritance:rIn WSL, una chiave sotto /mnt/c può non conservare i permessi Linux. Copiala in ~/.ssh dentro il file system Linux ed esegui lì chmod 600.
Lo stesso problema sul server: StrictModes
Il server ha un controllo simile, ma non vedi nessun avviso. Il client stampa solo Permission denied (publickey,password). e il motivo sta nel log del server, che per leggerlo ti serve un altro modo di entrare, come una console:
Authentication refused: bad ownership or modes for directory /home/user/.sshSu Debian e Ubuntu usa sudo journalctl -u ssh, e sulla maggior parte degli altri sistemi journalctl -u sshd. Questo è ciò che abbiamo visto su OpenSSH 10.0 di Debian 13, con StrictModes yes, il valore predefinito:
| Modifica | Risultato |
|---|---|
Directory home 777 | Rifiutato, bad ownership or modes for directory |
~/.ssh scrivibile dal gruppo, il gruppo è root | Rifiutato, stesso messaggio |
authorized_keys scrivibile dal gruppo, il gruppo è root | Rifiutato, bad ownership or modes for file |
authorized_keys di proprietà di root, modo 600 | Rifiutato, Could not open user 'user' authorized keys |
authorized_keys modo 644 | Il login funziona |
~/.ssh modo 755 | Il login funziona |
La build di Debian ha consentito la scrittura al gruppo anche quando il gruppo era il gruppo privato dell'utente, quindi non aspettarti lo stesso su ogni sistema. L'impostazione sicura è la stessa ovunque. Esegui questo come l'utente sul server:
chmod go-w ~
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R "$USER" ~/.sshSe esegui l'ultima riga tramite sudo, scrivi il nome dell'utente al posto di $USER.
Non impostare StrictModes no. Fa funzionare il login, come abbiamo confermato, ma accetta anche un file authorized_keys che altri utenti potrebbero aver potuto modificare. Per vedere il valore attuale:
sudo sshd -T | grep -i strictmodesSe i modi sono giusti e la chiave viene comunque rifiutata, vedi Permission denied (publickey).
Domande
Che permessi deve avere una chiave privata SSH?
600, così solo tu puoi leggerla e scriverla. Va bene anche 400, sola lettura. Qualsiasi accesso per gruppo o altri fa ignorare la chiave a ssh.
Che permessi devono avere ~/.ssh e authorized_keys?
700 per ~/.ssh e 600 per authorized_keys. Le chiavi pubbliche che finiscono in .pub possono restare a 644.
Si può disattivare il controllo dei permessi?
Sul client no. Sul server StrictModes no salta il suo controllo, ma accetta anche un file authorized_keys che altri potrebbero aver modificato, quindi correggi i permessi.
Fonti
- ssh(1), manuale OpenBSD
- sshd_config(5), StrictModes
- Troubleshoot connecting to an EC2 Linux instance, AWS