Prima le chiavi, poi le password
La migliore password SSH è quella che non ti serve più. Con una chiave il server controlla una firma e nessun segreto attraversa la rete, quindi chi intercetta quello che scrivi o un server falso non ottiene nulla di utile. Crea una chiave e installala sul server:
ssh-keygen -t ed25519 -C "you@laptop"
ssh-copy-id -i ~/.ssh/id_ed25519.pub deploy@203.0.113.10Poi provala e spegni l'accesso con password sul server, come spiegato in come disattivare l'accesso SSH con password. La configurazione completa della chiave è in come generare una chiave SSH Ed25519.
Le password restano per motivi concreti: apparati che accettano solo quelle, account che non gestisci tu, sudo sul server e il primo accesso prima di installare una chiave. Sono queste che vanno conservate bene.
Perché sshpass -p è una cattiva idea
sshpass scrive una password in ssh al posto tuo. La sua forma più comune è anche la più debole:
sshpass -p 'S3cret!' ssh deploy@203.0.113.10La password fa parte della riga di comando. Mentre il comando gira, qualsiasi utente della macchina può leggerla con ps, e resta salvata nella cronologia della shell. Il suo stesso manuale definisce -p l'opzione meno sicura. Le altre due forme sono migliori:
sshpass -f ~/.ssh/web.pass ssh deploy@203.0.113.10
SSHPASS='S3cret!' sshpass -e ssh deploy@203.0.113.10-f legge la prima riga di un file, che deve essere leggibile solo da te (chmod 600). -e legge la variabile SSHPASS, che resta visibile ai processi che girano con il tuo utente. Altre due trappole: sshpass non sa rispondere alla domanda sulla chiave dell'host, quindi su un server nuovo fallisce con codice di uscita 6, e a quel punto molti aggiungono StrictHostKeyChecking=no, che toglie la protezione contro un server falso. Accetta invece la chiave dell'host una volta a mano.
Tenere le password nel portachiavi di sistema
Invece di un file, lascia la password al sistema operativo. Sul Mac salvala nel portachiavi di login. Con -w in fondo e senza valore, il comando chiede la password, così non compare mai sulla riga di comando:
security add-generic-password -a deploy -s ssh-web -wRileggila solo per il comando che ne ha bisogno:
SSHPASS="$(security find-generic-password -a deploy -s ssh-web -w)" sshpass -e ssh deploy@webSui desktop Linux, secret-tool fa lo stesso con il portachiavi di GNOME o KWallet:
secret-tool store --label='ssh web' service ssh host web user deploy
secret-tool lookup service ssh host web user deployIl portachiavi si sblocca quando fai login e tiene la password cifrata sul disco. Qualsiasi programma che gira con il tuo utente può comunque chiederla, ed è per questo che la prima risposta resta una chiave.
Conservare allo stesso modo le passphrase delle chiavi
Una chiave dovrebbe avere una passphrase, e il portachiavi può ricordarla perché tu la scriva una volta sola. Sul Mac:
ssh-add --apple-use-keychain ~/.ssh/id_ed25519Host *
UseKeychain yes
AddKeysToAgent yesI dettagli, compreso cosa succede dopo un riavvio, sono in come usare ssh-agent con il Portachiavi di macOS. Su Linux lo stesso ruolo lo svolge ssh-agent o il portachiavi del desktop.
Cosa deve fare un gestore di password SSH
Un gestore di password generico conserva il segreto. Per SSH contano alcune cose in più:
- Cifratura sul tuo dispositivo, con una password o lo sblocco del sistema per aprirlo. Se sincronizza, il server deve vedere solo dati cifrati. La guida al vault cifrato end-to-end elenca le domande da fare.
- Un accesso per tanti server. Un utente con la sua password o chiave, salvato una volta e collegato a ogni server, così una modifica si fa in un posto solo.
- Chiavi e password insieme, così un server che passa a una chiave mantiene la stessa voce.
- Scrittura solo su richiesta. La password va al prompt che la chiede, non negli appunti, non in un file.
Un gestore di chiavi SSH con vault cifrato copre questi punti in un solo posto, accanto ai server stessi.
Errori da evitare
- Password negli script o in un repository. Finiscono in backup, log e copie di altre persone.
- Password nella cronologia della shell. In bash imposta
HISTCONTROL=ignorespacee inizia il comando con uno spazio per tenerlo fuori. In zsh usasetopt HIST_IGNORE_SPACE. - Una sola password di root condivisa in un team. Dai a ogni persona un account e una chiave, e usa
sudo. - La stessa password ovunque. Una sola violazione apre allora ogni server.
- Password negli appunti. I gestori degli appunti e gli appunti sincronizzati ne tengono una copia.
Domande
È sicuro conservare le password SSH in un gestore di password?
Sì, se il gestore cifra i dati sul tuo dispositivo e chiede una password o lo sblocco del sistema per aprirsi. È molto più sicuro di un file di testo, di uno script o di una nota. Una chiave resta comunque meglio di qualsiasi password salvata.
Perché sshpass -p non è sicuro?
La password fa parte della riga di comando, quindi chiunque sulla macchina può vederla con ps mentre il comando gira, e finisce nella cronologia della shell. sshpass -e o -f evitano entrambe le cose.
Posso mettere una password SSH in ~/.ssh/config?
No. OpenSSH non ha un'opzione per la password nel file di configurazione, ed è voluto. Il file può indicare una chiave con IdentityFile, e la passphrase della chiave può stare nel portachiavi di sistema.
Devo usare la stessa password su più server?
No. Un server compromesso apre poi tutti gli altri. Se devi usare le password, usane una diversa per server e tienile in un gestore.
Fonti
- sshpass(1), manuale Debian
- security(1), manuale macOS
- secret-tool(1), libsecret
- ssh_config(5), manuale OpenBSD
- ssh-keygen(1), manuale OpenBSD