Il formato
# Deploy key, added for the release job
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAINH9eelf0P7eT5ue6SualUXFrh1c9p3Maaem93iZtC2Q you@laptop
from="203.0.113.10",restrict ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAINxDNsPpUAbI52nc1OduztL+ backup-jobLeggendo una riga da sinistra a destra:
- Opzioni, facoltative. Separate da virgole, senza spazi a meno che siano tra virgolette doppie.
- Tipo di chiave, come
ssh-ed25519ossh-rsa. - La chiave, una lunga stringa in base64.
- Un commento, facoltativo. Serve solo a te.
Le righe vuote e quelle che iniziano con # vengono ignorate. Una riga senza senso viene saltata e le righe successive funzionano comunque.
Questi errori ti fanno perdere la chiave senza avvisi, e vedi solo Permission denied:
- Una chiave spezzata su due righe, di solito incollando in un editor che manda a capo il testo. Ogni chiave deve stare su una sola riga.
- Una chiave senza il tipo all'inizio.
- Uno spazio dopo una virgola nelle opzioni, come in
from="203.0.113.10", restrict.
Ti serve una chiave da mettere lì? Vedi come generare una chiave SSH Ed25519.
Opzioni utili
| Opzione | Effetto |
|---|---|
restrict | Disattiva l'inoltro di porte, agent e X11, i terminali e ~/.ssh/rc. |
command="..." | Esegue questo comando qualunque cosa abbia chiesto il client. |
from="..." | Il login deve arrivare da uno di questi indirizzi o nomi. Funzionano CIDR e pattern. |
permitopen="host:port" | Limita ssh -L a questa destinazione. |
expiry-time="20991231" | La chiave smette di funzionare dopo questa data. |
cert-authority | La riga è una autorità di certificazione, non una chiave utente. Vedi certificati SSH. |
verify-required | Per le chiavi FIDO: ogni firma deve includere un PIN o un controllo simile. |
Per esempi funzionanti, vedi come limitare una chiave a un solo comando.
Permessi
Le impostazioni sicure, eseguite come utente sul server:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keysSe li hai creati come root, correggi anche il proprietario:
sudo chown -R user:user /home/user/.sshEcco cosa è successo nelle nostre prove e cosa diceva il log del server:
| Impostazione | Risultato |
|---|---|
authorized_keys con modo 600 o 644 | Funziona |
authorized_keys con modo 666 | Rifiutato: Authentication refused: bad ownership or modes for file /home/user/.ssh/authorized_keys |
~/.ssh con modo 700 o 755 | Funziona |
~/.ssh con modo 777 | Rifiutato: Authentication refused: bad ownership or modes for directory /home/user/.ssh |
| File di proprietà di root, modo 644 | Funziona, perché l'utente può leggerlo |
| File di proprietà di root, modo 600 | Rifiutato: Could not open user 'user' authorized keys '/home/user/.ssh/authorized_keys': Permission denied |
Il controllo si chiama StrictModes ed è attivo per impostazione predefinita. Lascialo attivo. Una home con modo 775 ha passato il controllo sul nostro sistema Debian, dove il gruppo contiene solo quell'utente, ma è una modifica di Debian, quindi altri sistemi possono rifiutarla. Il client vede solo Permission denied, quindi leggi sempre il log del server. Vedi come fare il debug di una connessione SSH.
Quale riga vince
Quando una chiave compare più volte, sshd legge dall'alto in basso e usa la prima riga che lascia passare il login. Si applicano solo le opzioni di quella riga. Ne derivano due conseguenze da conoscere:
- Una riga semplice sopra una con restrizioni la vanifica. Con la chiave elencata prima senza opzioni e poi con
command="...", il login ottiene una sessione normale e senza restrizioni. - Una riga la cui condizione fallisce non interrompe la ricerca. Se la prima riga ha un
from=che non corrisponde, o unexpiry-timenel passato, la riga successiva con la stessa chiave può comunque far passare il login. Per escludere una chiave, elimina tutte le sue righe.
Cambiare dove si trova il file
L'impostazione del server AuthorizedKeysFile indica dove cercare. Vedi il valore attuale con:
sudo sshd -T | grep -i authorizedkeysfileIl valore predefinito è .ssh/authorized_keys .ssh/authorized_keys2, quindi funziona anche una chiave in un authorized_keys2 dimenticato. Controlla se ce n'è uno quando rimuovi un accesso.
Una modifica comune è tenere i file fuori dalle home, dove solo root può modificarli:
# /etc/ssh/sshd_config.d/10-keys.conf
AuthorizedKeysFile /etc/ssh/authorized_keys/%u%u è il nome utente e %h la home. I percorsi relativi partono dalla home. Ogni utente deve poter leggere il proprio file, per esempio con modo 644 e root come proprietario. Crea quei file prima di ricaricare sshd e tieni aperta una sessione mentre provi.
Per prendere le chiavi da un'altra fonte, come un servizio di directory, usa AuthorizedKeysCommand. Vedi sshd_config(5).
Vedere cosa c'è nel file
ssh-keygen -lf ~/.ssh/authorized_keysStampa un'impronta per ogni chiave. Su una riga con opzioni, il testo delle opzioni compare dove ti aspetteresti il commento, per esempio 256 SHA256:NxFS... restrict,command="/usr/local/bin/ssh-allow" (ED25519). L'impronta resta comunque corretta.
Domande
Dove si trova il file authorized_keys?
Di base in ~/.ssh/authorized_keys, nella home dell'account con cui entri. L'impostazione AuthorizedKeysFile del server può indicare un altro percorso; controllala con sudo sshd -T | grep -i authorizedkeysfile.
Devo riavviare sshd dopo aver modificato authorized_keys?
No. sshd legge il file a ogni accesso, quindi la modifica vale dalla connessione successiva.
Perché SSH chiede ancora la password dopo che ho aggiunto la chiave?
Di solito i permessi sono troppo aperti, la chiave è spezzata su due righe o è finita nell'account sbagliato. Il log del server indica il motivo; il client mostra solo la richiesta di password o Permission denied.