Aggiungi una chiave SSH e disattiva le password

Genera la chiave sulla macchina su cui lavori

Non sul server. La metà privata non dovrebbe mai esistere su un host a cui potresti perdere l'accesso, e copiarla in giro vanifica lo scopo di averla.

ssh-keygen -t ed25519 -a 100 -C "laptop-2026"

-a 100 imposta il numero di iterazioni KDF che proteggono la passphrase, che è l'unica cosa che separa un laptop rubato dalla tua flotta. Usa una passphrase. Se possiedi un token hardware, usalo invece:

ssh-keygen -t ed25519-sk -O resident -C "token-1"

Installa la metà pubblica

ssh-copy-id -i ~/.ssh/id_ed25519.pub deploy@<ipv4>

A mano, da una sessione root, se l'account non ha ancora una password:

install -d -m 700 -o deploy -g deploy /home/deploy/.ssh
install -m 600 -o deploy -g deploy /dev/null /home/deploy/.ssh/authorized_keys
cat >> /home/deploy/.ssh/authorized_keys

Incolla la singola riga, poi Ctrl-D. I permessi contano più di quanto ci si aspetti: sshd rifiuta una home o una directory .ssh scrivibile dal gruppo e si spiega solo nel log del demone, mai al client.

Limita la chiave mentre sei lì

Le opzioni in authorized_keys si applicano per chiave. restrict disattiva tutto, e poi aggiungi di nuovo ciò di cui la chiave ha realmente bisogno:

restrict,pty ssh-ed25519 AAAAC3Nza... deploy@laptop

Una chiave che esiste per eseguire un lavoro dovrebbe poter eseguire un solo lavoro:

restrict,command="/usr/local/bin/backup-receive" ssh-ed25519 AAAAC3Nza... backup

Testa prima di bloccare

Lascia la prima sessione connessa. Da un secondo terminale:

ssh -o PreferredAuthentications=publickey deploy@<ipv4> id

Se stampa il tuo uid, il percorso della chiave funziona. Se non lo fa, ssh -vvv sul client e journalctl -u ssh -n 50 sul server diranno insieme quale lato è insoddisfatto. Sono i permessi circa la metà delle volte e il nome utente sbagliato per la maggior parte del resto.

Disattiva le password

cat > /etc/ssh/sshd_config.d/20-keys-only.conf <<EOF
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitEmptyPasswords no
AuthenticationMethods publickey
EOF
sshd -t && systemctl reload ssh

AuthenticationMethods publickey è la cintura sotto le bretelle. Anche se un successivo drop-in riattiva silenziosamente le password, il demone rifiuta comunque tutto ciò che non è una chiave.

Conferma dal client che la porta è chiusa:

ssh -o PreferredAuthentications=password deploy@<ipv4>

Il risultato atteso è Permission denied (publickey).

Chiavi al momento del deploy

Il pannello mantiene un elenco di chiavi per account. Seleziona quelle che desideri e cloud-init le scrive durante il primo avvio, il che significa che un'istanza può esistere per la prima volta con l'autenticazione tramite password già disattivata. Allegare la chiave all'ordine trasforma i dieci minuti di cui sopra in uno.

Quando perdi la chiave

Non esiste un recupero basato sull'identità qui, perché non deteniamo alcuna identità. La console out-of-band è la via di ritorno: raggiunge l'istanza tramite un percorso che non tocca mai sshd, e da una shell di recovery puoi aggiungere una nuova chiave e continuare.

Tieni una seconda chiave su una seconda macchina e non avrai mai bisogno di leggere questo articolo.