Come funzionano le chiavi host e utente di SSH, perché la scelta predefinita è Ed25519 con passphrase e come impostare un accesso con chiave e fare hardening su una VM di laboratorio tua.
SSH (Secure Shell) è il protocollo che la maggior parte delle persone usa per accedere a server Linux, macchine virtuali di laboratorio e host Git. Apre una shell su un canale cifrato, e lo stesso canale può copiare file o inoltrare porte. Ha tre compiti. Cifra il traffico, così nessuno sul percorso di rete può leggerlo. Dimostra al server chi sei. Dimostra a te chi è il server.
Le chiavi svolgono il secondo compito senza inviare una password sulla rete. Una password si può indovinare o rubare con il phishing. Una coppia di chiavi funziona in modo diverso. Il server conserva solo la metà pubblica. Per accedere, il tuo client firma un challenge con la metà privata e il server controlla la firma. La chiave privata non lascia mai la tua macchina.
In alcuni casi SSH non ti protegge, e quei casi contano quanto il protocollo. Se il tuo computer è compromesso, un malware eseguito con il tuo utente può leggere il file della chiave privata o chiedere al tuo agent di firmare. Se la chiave privata viene rubata e la passphrase è debole, un attaccante può provare a indovinarla offline. Se accetti l'identità di un server senza controllarla, potresti parlare con qualcuno che non è affatto il server.
SSH usa due tipi diversi di chiavi, e capita spesso di confonderli.
Le chiavi host identificano il server. Ogni server SSH ne ha una o più, di solito in /etc/ssh/ssh_host_*_key. La parte privata resta sul server. La parte pubblica viene presentata a ogni client che si collega. La prima volta che la vede, il client la salva in known_hosts. Nelle connessioni successive, una chiave host cambiata fa scattare un avviso.
Le chiavi utente identificano te. Generi la coppia sulla tua macchina. La chiave privata resta con te. La chiave pubblica va sul server, in ~/.ssh/authorized_keys per l'account che vuoi usare.
La differenza ha conseguenze pratiche. Copiare la tua chiave privata su un server dà a quel server, e a chiunque possa leggerla, il materiale per agire come te ovunque la chiave sia accettata. Ignorare un avviso sulla chiave host significa che potresti inviare la password o i comandi a un impostore.
OpenSSH gestisce diversi tipi di chiave. RSA funziona ancora, ma le nuove chiavi RSA dovrebbero avere almeno 3072 bit, e le righe della chiave pubblica diventano lunghe. Le chiavi Ed25519 sono corte, veloci da verificare e standardizzate per SSH nella RFC 8709. OpenSSH 9.5 e versioni successive usano Ed25519 come tipo predefinito di ssh-keygen. Ed25519 è la scelta predefinita giusta per una chiave di laboratorio, a meno che un sistema che devi raggiungere accetti solo un tipo più vecchio.
Una passphrase cifra il file della chiave privata sul disco. Senza passphrase, chiunque copi il file può usare la chiave. Se la imposti, servono il file e la passphrase. Questo protegge dagli incidenti più comuni: un backup finito nel posto sbagliato, una chiave lasciata in una cartella condivisa, un file sincronizzato per errore su un cloud drive. La passphrase non serve più una volta che la chiave è caricata in un agent e un malware gira con il tuo utente. Usa una passphrase lunga, salvala in un password manager e conserva un backup del file della chiave in un posto sicuro.
La RFC 4253 descrive il livello di trasporto. A grandi linee, una connessione passa da queste fasi:
known_hosts. Se l'host è nuovo, il client mostra il fingerprint e ti chiede di confermarlo.authorized_keys, invia un challenge. Il tuo client firma il challenge con la chiave privata e il server controlla la firma.Nota da dove viene la fiducia. Il passo 3 riguarda il server. Il passo 4 riguarda te. Se salti il controllo del fingerprint al passo 3, il resto dell'handshake funziona a vantaggio di chiunque abbia risposto.
Un fingerprint è un hash breve di una chiave pubblica. OpenSSH mostra per impostazione predefinita fingerprint SHA256. Due persone possono confrontare un fingerprint per confermare di avere la stessa chiave pubblica, senza leggere ad alta voce la chiave intera.
I comandi qui sotto sono stati eseguiti su una macchina Windows 11 con OpenSSH 9.9p2 (ssh -V), in Git Bash. La chiave era una copia temporanea creata per questa prova, con passphrase vuota, così da poter mostrare qui l'output. La tua chiave reale avrà un fingerprint diverso.
ssh-keygen -t ed25519 -C 'lab-key' -f ./lab_ed25519 -N ''
ssh-keygen -lf ./lab_ed25519.pubOutput osservato:
256 SHA256:2BAyZTrHADdiG1FNwfCwb/fC5vSVZPwfGnZjRaaExc4 lab-key (ED25519)ssh-keygen -lvf stampa lo stesso fingerprint con un disegno random-art. Il disegno rende più facile accorgersi di un cambiamento, ma quello che devi confrontare è il testo del fingerprint.
Ti serve una macchina virtuale o un'istanza cloud che possiedi e controlli, con un server OpenSSH attivo e un account che può usare sudo. Va bene una VM locale in VirtualBox o Hyper-V. Va bene anche una piccola istanza cloud che paghi e puoi cancellare. Non eseguire questi passi su una macchina che appartiene a qualcun altro.
ssh-keygen -t ed25519 -C 'lab-key' -f ~/.ssh/lab_ed25519Quando ti viene chiesto, inserisci una passphrase lunga. Il comando crea due file: lab_ed25519 (privato) e lab_ed25519.pub (pubblico). Solo il file .pub è fatto per uscire dalla tua macchina.
ssh-keygen -lf ~/.ssh/lab_ed25519.pubAnnota questo fingerprint, o almeno i primi caratteri. Lo confronterai di nuovo più avanti.
chmod 600 ~/.ssh/lab_ed25519Su Linux e macOS, ssh rifiuta una chiave privata leggibile da altri utenti. Su Windows, OpenSSH controlla le ACL del file invece dei bit di modalità Unix. Su questa macchina Windows, chmod 600 è stato eseguito senza errori, ma dopo ls -l mostrava ancora -rw-r--r--. Non dare per scontato che lì i bit siano cambiati. Se ssh si lamenta dei permessi su Windows, controlla il file con icacls e togli l'accesso agli altri account.
ssh-copy-id -i ~/.ssh/lab_ed25519.pub youruser@your-lab-vmQuesta è l'unica volta in cui digiti di proposito la password dell'account. Il comando aggiunge la chiave pubblica a ~/.ssh/authorized_keys sulla VM.
La prima connessione alla VM ti mostra anche il fingerprint di una chiave host. Confrontalo con quello reale. Sulla VM, esegui:
ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pubSe i due fingerprint coincidono, digita yes. Se non coincidono, fermati. Scopri il motivo prima di continuare. Una differenza può significare che hai reinstallato la VM, o che qualcuno si è messo tra te e la VM.
Questo passo non è stato eseguito qui, perché su questa macchina non c'era una VM disponibile. Per questo i comandi dei passi da 4 a 6 sono riportati senza output. Puoi controllarli uno per uno sulla tua VM.
ssh -i ~/.ssh/lab_ed25519 youruser@your-lab-vmIl client ti chiede la passphrase della chiave, e non la password dell'account. Se ottieni una shell, la chiave funziona. Tieni aperta questa sessione per il passo successivo.
Sulla VM:
sudo sed -i 's/^#\?PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
sudo sshd -t && sudo systemctl restart sshLa riga sed sostituisce la riga PasswordAuthentication, che sia commentata o no. sshd -t controlla la sintassi della configurazione e interrompe la catena se fallisce. systemctl restart ssh applica la modifica. Su Fedora e sugli altri sistemi della famiglia RHEL il servizio si chiama sshd, quindi usa quel nome.
Tre cose vanno storte spesso a questo punto:
/etc/ssh/sshd_config include file da /etc/ssh/sshd_config.d/, e vince il primo valore letto per una parola chiave. Controlla il valore che sshd usa davvero:sudo sshd -T | grep -i '^passwordauthentication'Dopo la modifica, l'output dovrebbe essere passwordauthentication no. Se dice ancora yes, trova il file che lo imposta e correggilo lì.
sed modifica solo una riga che esiste. Se non c'è alcuna riga PasswordAuthentication, si applica il valore predefinito, e la pagina man sshd_config(5) dice che è yes. Aggiungi tu la riga:echo 'PasswordAuthentication no' | sudo tee -a /etc/ssh/sshd_configPoi verifica dalla tua macchina che l'accesso con password venga rifiutato:
ssh -o PubkeyAuthentication=no -o PreferredAuthentications=password youruser@your-lab-vmLa connessione dovrebbe fallire con un messaggio di permesso negato. Fai tu questa verifica sulla VM che possiedi. Su questa macchina non è stata eseguita.
Digitare la passphrase a ogni connessione alla lunga stanca. ssh-agent tiene in memoria la chiave decifrata per la durata della sessione, così digiti la passphrase una volta sola.
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/lab_ed25519
ssh-add -lssh-add -l elenca i fingerprint che l'agent ha in memoria. Su questa macchina Windows, ssh-add -l è stato eseguito senza un agent attivo e ha stampato Could not open a connection to your authentication agent. con codice di uscita 2. Windows usa per questo il servizio OpenSSH Authentication Agent. Avvia quel servizio dalla console Servizi o da una PowerShell di amministratore. È una modifica al tuo sistema, quindi falla tu e solo se vuoi che l'agent sia attivo.
Un agent è comodo, ed è anche un bersaglio. Chiunque possa parlare con il socket dell'agent mentre sei connesso può chiedergli di firmare. Per questo evita l'inoltro dell'agent (ssh -A) verso host di cui non ti fidi del tutto. Un utente root sull'host remoto può usare il tuo agent inoltrato. Se devi raggiungere un host privato tramite un bastion, usa invece un jump host:
ssh -J youruser@bastion youruser@private-vmIl client conserva le chiavi host in ~/.ssh/known_hosts, una riga per host e tipo di chiave. Se imposti HashKnownHosts yes, le righe vengono salvate come hash, così chi legge il file non vede i nomi degli host.
Per cercare un host:
ssh-keygen -F your-lab-vmPer rimuovere una voce dopo aver ricostruito una VM e ottenuto una nuova chiave host:
ssh-keygen -R your-lab-vmFallo solo quando sai perché la chiave è cambiata. Una chiave host cambiata è un avvertimento, e non un fastidio da togliere di mezzo. Se rimuovi la vecchia voce senza controllare il nuovo fingerprint, ti abitui a ignorare il prossimo avviso, e il prossimo potrebbe essere vero.
.pub va sui server, sugli host Git o ad altre persone.authorized_keys..pub in authorized_keys.~/.ssh dovrebbe essere 700 e authorized_keys dovrebbe essere 600. Modalità più permissive possono far ignorare la chiave a sshd. Controlla i log di sshd quando un accesso con chiave fallisce.lab_ed25519 per il laboratorio e un'altra chiave per GitHub.yes.ssh-copy-id due volte non fa danni, ma aggiungere una chiave a mano più volte rende il file più difficile da controllare. Rimuovi le chiavi che non usi più.Quando il laboratorio funziona, qualche passo rende l'uso quotidiano più sicuro e ordinato.
~/.ssh/config. Dai un alias a ogni host, imposta IdentityFile e aggiungi IdentitiesOnly yes, così il client propone solo la chiave che hai scelto. In questo modo il client non prova contro un server tutte le chiavi del tuo agent.ssh-keygen -t ed25519-sk. In questo caso la parte privata non si può copiare fuori dal dispositivo. Controlla la versione di OpenSSH e il supporto della tua chiave prima di farci affidamento.ssh-keygen e sshd_config descrivono tutte le opzioni che incontrerai. La RFC 4253 spiega il livello di trasporto, e la RFC 8709 tratta Ed25519 in SSH.Se modalità dei file e proprietà ti sono ancora nuove, leggi prima l'articolo precedente su file e permessi su Linux. Il prossimo articolo tratta le reti Docker isolate per i laboratori, che puoi usare per tenere il traffico del laboratorio lontano dalla tua rete di tutti i giorni.
ssh-keygen(1): https://man.openbsd.org/ssh-keygensshd_config(5): https://man.openbsd.org/sshd_configLinux e strumenti per sviluppatori
Impara pipe, redirezioni, variabili, loop, codici di uscita e set -euo pipefail, poi usali per contare gli accessi falliti e calcolare l'hash di una cartella.
Linux e strumenti per sviluppatori
Proprietari e gruppi Linux, bit rwx, chmod, umask e setuid, con un lab che prova l'accesso come secondo utente e trova i permessi rischiosi sui file.
Linux e strumenti per sviluppatori
GitHub spiegato a chi comincia: che cosa fanno Git e GitHub, i termini che ti servono, una prova locale con Git e come controllare un progetto prima di eseguirlo.