 |
Quando si parla di autenticazione SSH, il dibattito ruota quasi sempre intorno alla crittografia asimmetrica: chiave pubblica, chiave privata, algoritmi robusti, curve ellittiche, lunghezze delle chiavi. È naturale pensarlo: è lì che risiede la forza matematica del sistema.
Eppure, molti incidenti reali non nascono da una debolezza degli algoritmi, ma da una scelta apparentemente secondaria, spesso fatta per comodità o fretta operativa: utilizzare una chiave privata senza passphrase.
Questo articolo non vuole demonizzare questa scelta, ma spiegarla in modo lucido. Vedremo cos’è davvero la passphrase, quale problema risolve, quali invece non risolve, e perché la sua assenza rappresenta un rischio concreto in molti scenari reali.
🤔 Cos’è davvero una passphrase SSH
La prima cosa da chiarire è che la passphrase non fa parte della crittografia asimmetrica. Non è un elemento dell’algoritmo RSA o ED25519, non viene inviata al server e non influisce sul processo di autenticazione remoto.
La passphrase è una protezione locale, applicata esclusivamente al file che contiene la chiave privata. Serve a cifrare quel file in modo che, se qualcuno lo copia o lo ruba, non possa usarlo immediatamente.
In altre parole, la passphrase non protegge il server: protegge il possesso della chiave privata.
Un buon paragone è quello con una smart card: la carta contiene il segreto crittografico, ma senza il PIN non è utilizzabile. Allo stesso modo, una chiave privata cifrata con passphrase rimane inutile finché non viene sbloccata.
🫤 Cosa succede quando la passphrase è assente
Quando una chiave privata non è protetta da passphrase, il suo utilizzo è immediato. Chiunque ottenga una copia del file può usarlo per autenticarsi senza alcun ulteriore ostacolo.
Dal punto di vista operativo questo è comodo, ma dal punto di vista della sicurezza introduce una fragilità importante: la sicurezza dell’accesso SSH diventa equivalente alla segretezza assoluta di un singolo file.
Per rendere il concetto concreto, basta immaginare uno scenario molto comune: un laptop rubato o smarrito. Se su quel laptop è presente una chiave privata senza passphrase, l’attaccante non deve “rompere” nulla. Gli basta copiare il file e usarlo:
ssh -i id_rsa user@serverDa quel momento, ha accesso agli stessi server, con gli stessi privilegi, senza lasciare tracce anomale.
😮 Furto del file e compromissione silenziosa
Il problema più grave di una chiave rubata senza passphrase non è solo l’accesso, ma il modo in cui avviene.
Dal punto di vista del server SSH, l’autenticazione è perfettamente valida. Nei log comparirà un accesso tramite chiave pubblica autorizzata, indistinguibile da quello del legittimo proprietario. Questo rende la compromissione silenziosa e persistente.
Un attaccante può, ad esempio:
- accedere periodicamente al server per esfiltrare dati
- installare una backdoor o un nuovo utente
- aggiungere altre chiavi in
authorized_keysper mantenere l’accesso
Tutto questo senza mai usare password, senza tentativi falliti, senza allarmi evidenti.
Con una passphrase, il furto del file non equivale automaticamente al furto dell’accesso. Il file resta cifrato e l’attaccante deve superare una barriera aggiuntiva, spesso sufficiente a fermare o ritardare l’abuso.
😨 Malware e uso immediato della chiave
Un altro scenario realistico è quello di un malware sul sistema locale. Molti malware moderni non cercano di “rompere” SSH: cercano semplicemente chiavi già pronte all’uso.
Una chiave privata senza passphrase può essere:
- letta da
~/.ssh - inviata all’esterno
- utilizzata immediatamente da un altro host
In questo caso l’attaccante non ha nemmeno bisogno di restare sul sistema compromesso. Può usare la chiave da remoto, rendendo molto più difficile correlare l’incidente all’infezione originale.
Con una passphrase, invece, il file sottratto è inutilizzabile finché non viene sbloccato.
😡 Backup, snapshot e copie involontarie
Un aspetto spesso sottovalutato è la proliferazione involontaria delle chiavi private. Nel tempo, una chiave può finire in backup automatici, snapshot di macchine virtuali, immagini di container, NAS o archivi cloud.
Immagina un vecchio backup ripristinato mesi dopo in un ambiente di test, o scaricato da qualcuno che non dovrebbe avervi accesso. Se la chiave non ha passphrase, quella copia diventa immediatamente una credenziale valida, anche se il sistema originale non esiste più.
La passphrase introduce una separazione netta: anche se il file viene copiato decine di volte, non equivale automaticamente a un accesso.
🤓 Cosa la passphrase non protegge
È importante essere altrettanto chiari su ciò che la passphrase non fa.
Se una chiave è già caricata in memoria tramite ssh-agent, oppure se un attaccante ha accesso a una sessione sbloccata, la passphrase non offre alcuna protezione aggiuntiva. In quel momento la chiave è già utilizzabile.
Questo chiarisce un punto fondamentale: la passphrase non è una difesa contro l’uso legittimo della chiave, ma contro l’uso non autorizzato del file.
👿 Perché l’assenza della passphrase è un rischio strutturale
Dal punto di vista della sicurezza, una chiave privata senza passphrase rappresenta un punto di fallimento unico. Non esiste una fase intermedia di degradazione: o la chiave è segreta, o è completamente compromessa.
Questo è particolarmente critico perché:
- dalla chiave privata è sempre ricavabile la chiave pubblica
- una singola chiave spesso abilita accessi privilegiati
- un attaccante può usarla senza limiti di tentativi o frequenza
Una chiave rubata può essere usata oggi, domani o tra sei mesi, senza che il proprietario se ne accorga.
🤔 Perché allora così tante chiavi non hanno passphrase
La risposta non è l’ignoranza, ma la praticità. Inserire una passphrase a ogni connessione è percepito come un ostacolo, soprattutto in contesti di automazione, scripting o integrazione continua.
In molti ambienti si preferisce eliminare la passphrase piuttosto che progettare una gestione più attenta delle chiavi. È una scelta comprensibile, ma spesso fatta senza una piena valutazione delle conseguenze operative in caso di compromissione.
🧠 Mitigare il problema senza sacrificare l’usabilità
Strumenti come ssh-agent o Pageant permettono di inserire la passphrase una sola volta e mantenere la chiave sbloccata in memoria, riducendo drasticamente l’impatto sull’usabilità.
Un’altra misura fondamentale è la separazione delle chiavi: usare chiavi diverse per utenti, automazione e servizi limita il danno nel caso una singola chiave venga sottratta.
Nei casi in cui una chiave senza passphrase è davvero necessaria, questa scelta dovrebbe essere compensata con restrizioni lato server, come comandi forzati o limitazioni di origine.
Esempio ssh-agent
ssh-agent permette di:
-
inserire la passphrase una sola volta
-
mantenere la chiave sbloccata in memoria
ssh-add ~/.ssh/id_rsa😏 Quando è accettabile non usare una passphrase
Esistono scenari in cui l’assenza della passphrase è accettabile, ma devono essere casi consapevoli e ben delimitati: account di servizio isolati, ambienti effimeri o chiavi fortemente limitate nelle loro capacità.
In questi contesti, la mancanza della passphrase non è una dimenticanza, ma una decisione progettuale, accompagnata da altre misure di sicurezza.
😍 Conclusione
La passphrase non rende la crittografia più forte.
Rende più difficile trasformare una perdita di file in una compromissione reale.
Una chiave privata senza passphrase funziona perfettamente, ma al primo leak non fallisce: viene semplicemente abusata. Comprendere come e perché questo accade è il primo passo per progettare accessi SSH più sicuri e realistici.
Follow me #techelopment
Official site: www.techelopment.it
facebook: Techelopment
instagram: @techelopment
X: techelopment
Bluesky: @techelopment
telegram: @techelopment_channel
whatsapp: Techelopment
youtube: @techelopment
