Ho visto questa scena ripetersi decine di volte negli ultimi dieci anni. Un sistemista o un programmatore apre il terminale, segue una guida trovata a caso su un blog del 2018 e prova a Create SSH Keys on Windows convinto che basti premere invio tre volte. Due minuti dopo, si ritrova chiuso fuori dal server di produzione o, peggio, scopre che la sua chiave privata è stata salvata in una cartella sincronizzata su un cloud pubblico senza alcuna protezione. Il costo non è solo il tempo perso a resettare le credenziali; è il rischio concreto di un accesso non autorizzato che può costare migliaia di euro in danni alla reputazione o sanzioni per la protezione dei dati. Configurare male l'accesso remoto non è un piccolo errore tecnico, è una falla di sicurezza spalancata che aspetti solo di essere colpita.
L'illusione di PuTTY e il disastro dei formati proprietari
Per anni, il consiglio standard per chiunque volesse generare chiavi su sistemi Microsoft è stato quello di scaricare PuTTYgen. È un software storico, certo, ma oggi rappresenta uno dei principali punti di attrito per chi lavora in ambienti moderni. Ho visto interi team di sviluppo perdere giornate di lavoro perché avevano generato chiavi in formato .ppk, che però non funzionano nativamente con OpenSSH, Git Bash o le pipeline di automazione Linux.
Il problema qui è la frammentazione. Se usi un formato proprietario, ti costringi a usare software specifici che fanno da intermediari, aggiungendo uno strato di complessità inutile. La soluzione corretta oggi non passa per software esterni con interfacce grafiche obsolete, ma per l'integrazione nativa. Dal 2018, Windows 10 e 11 includono un client OpenSSH integrato che è identico a quello che trovi su Linux o macOS. Smetti di cercare programmi terzi. Apri il prompt dei comandi o PowerShell e usa lo strumento che il sistema ti mette già a disposizione. Risparmierai ore di conversioni manuali tra formati e non dovrai più combattere con errori di tipo "invalid format" quando provi a caricare la chiave su un server cloud moderno.
Non usare RSA se vuoi che i tuoi sistemi durino nel tempo
Molti pensano ancora che RSA a 2048 bit sia lo standard di riferimento. Non lo è più. Molte distribuzioni Linux recenti, come le ultime versioni di Fedora o Ubuntu, hanno iniziato a disabilitare il supporto predefinito per gli algoritmi di firma RSA più vecchi per motivi di sicurezza legati alle collisioni e alla potenza di calcolo moderna. Se insisti a generare queste chiavi, ti ritroverai presto con server che rifiutano la connessione senza spiegazioni chiare, costringendoti a interventi d'urgenza in piena notte.
La scelta professionale oggi ricade su Ed25519. Si basa sulla crittografia a curve ellittiche. È più veloce, incredibilmente più sicura e produce chiavi molto corte, il che le rende più facili da gestire e meno inclini a errori di copia-incolla. Quando decidi di Create SSH Keys on Windows, devi specificare esplicitamente questo algoritmo. Non accettare i valori predefiniti che il sistema ti propone se non sono aggiornati agli standard attuali. Una chiave Ed25519 è praticamente impossibile da forzare con le tecnologie odierne e garantisce che il tuo accesso rimanga valido anche quando i fornitori di cloud aggiorneranno i loro protocolli di sicurezza minimi il prossimo anno.
La gestione catastrofica delle passphrase e della memoria locale
Ecco dove la maggior parte delle persone fallisce miseramente: la sicurezza della chiave privata una volta creata. C'è questa idea pericolosa che non serva una passphrase perché "tanto il mio PC è protetto da password". È un errore fatale. Se un malware infetta la tua postazione o se perdi il portatile, chiunque entri in possesso del file della chiave avrà accesso immediato e totale a ogni server a cui quella chiave è associata.
Perché la passphrase non è opzionale
Ho assistito a casi in cui account amministrativi sono stati compromessi perché le chiavi erano archiviate in chiaro. Molti dicono che digitare la password ogni volta è frustrante. Hanno ragione, ma la soluzione non è eliminare la sicurezza, bensì usare l'agente SSH di Windows. Questo servizio, che spesso è disattivato di default, permette di caricare la chiave una volta all'avvio, sbloccarla con la passphrase e poi lasciarla in memoria in modo sicuro per tutta la sessione. In questo modo ottieni la comodità di un accesso rapido senza sacrificare la protezione dei tuoi asset digitali.
Il rischio delle cartelle condivise
Un altro sbaglio che vedo costantemente è salvare le chiavi dentro cartelle sincronizzate come OneDrive o Dropbox. Sembra comodo avere le chiavi su tutti i dispositivi, ma stai letteralmente caricando il "passepartout" di casa tua sul server di qualcun altro. La regola d'oro è che la chiave privata deve risiedere solo ed esclusivamente nella cartella .ssh del tuo profilo utente locale, con permessi di accesso ristretti solo al tuo account. Se provi a usarla da una cartella con permessi troppo larghi, OpenSSH su Windows spesso si rifiuterà persino di funzionare per proteggerti da te stesso.
Confronto tra un approccio dilettantistico e uno professionale
Vediamo come cambia la realtà operativa tra chi agisce d'istinto e chi segue una procedura basata sull'esperienza.
Lo scenario del dilettante si svolge così: scarica un tool grafico, genera una chiave RSA senza passphrase, la salva sul desktop per "trovarla subito" e poi la copia manualmente dentro un file di testo che invia via email al collega per farla installare sul server. Risultato: la chiave è ovunque, non è protetta, è in un formato vecchio e se il PC viene rubato, l'intera infrastruttura aziendale è compromessa. Il tempo impiegato è di circa 10 minuti, ma il debito tecnico e di sicurezza creato è immenso.
L'approccio del professionista invece segue una linea diversa. Apre PowerShell come amministratore per assicurarsi che il servizio SSH Agent sia attivo. Genera una chiave Ed25519 con una passphrase complessa, memorizzata in un password manager. La chiave viene salvata automaticamente nella cartella corretta con i permessi già impostati. Usa il comando appropriato per aggiungere la chiave all'agente, così da non dover ridigitare la password per il resto della giornata. Infine, distribuisce la chiave pubblica (e solo quella) tramite uno script di automazione o una piattaforma di gestione delle identità. Il tempo impiegato è lo stesso, 10 minuti, ma la sicurezza è ai massimi livelli e il sistema è pronto per scalare.
Dimenticare la manutenzione e la rotazione delle chiavi
Creare una chiave non è un evento unico nella vita. Le chiavi invecchiano, le persone cambiano lavoro e i computer vengono sostituiti. Molti professionisti pensano che una volta configurato l'accesso, il lavoro sia finito. Invece, la mancanza di una strategia di rotazione è ciò che permette a ex dipendenti o consulenti di mantenere accessi silenziosi per anni.
La disciplina della rotazione
Dovresti cambiare le tue chiavi almeno una volta all'anno. Sembra un eccesso di zelo finché non ti rendi conto che non sai più dove sono finiti tutti i frammenti della tua vecchia chiave pubblica. In ambito aziendale, questo processo deve essere centralizzato. Non puoi permettere che ogni singolo sviluppatore decida come e quando Create SSH Keys on Windows senza seguire uno standard interno. La coerenza è ciò che separa un'infrastruttura sicura da un caos ingestibile.
Gestione dei permessi sui file
Su Windows, il sistema dei permessi NTFS è molto diverso da quello POSIX di Linux. Spesso le persone copiano file di chiavi da un sistema all'altro e si ritrovano con l'errore "Permissions for private key are too open". Non è un bug, è una funzione di sicurezza. Devi imparare a usare il comando icacls o l'interfaccia di sicurezza avanzata di Windows per rimuovere l'ereditarietà dei permessi e lasciare l'accesso solo al tuo utente specifico. Senza questo passaggio, il client SSH bloccherà la connessione per evitare che altri utenti del sistema possano leggere la tua chiave.
Il mito della semplicità dei tutorial online
La maggior parte dei tutorial che trovi online sono scritti per darti una gratificazione immediata, non per proteggere il tuo lavoro a lungo termine. Ti dicono di copiare e incollare comandi senza spiegarti le implicazioni di ogni flag. Ad esempio, molti suggeriscono di usare l'opzione -t rsa -b 4096. Sebbene sia meglio di 2048, è comunque una scelta pigra rispetto alle alternative moderne.
Un altro mito è che le chiavi SSH siano "impossibili da perdere". Ho visto professionisti disperati perché avevano formattato il PC senza fare il backup della chiave privata, perdendo l'unico accesso possibile a server critici dove la password era stata disabilitata per sicurezza. La strategia corretta non è non fare il backup, ma fare un backup cifrato e offline. Stampa la chiave su carta o salvala su una chiavetta USB protetta da hardware e chiudila in una cassaforte. Non è paranoia, è gestione del rischio professionale basata su fatti concreti.
La verità sull'integrazione con Windows Subsystem for Linux (WSL)
Se lavori su Windows, probabilmente usi WSL. Qui nasce un altro grande equivoco: molti pensano di dover gestire due set diversi di chiavi, uno per Windows e uno per la distribuzione Linux interna. Questo raddoppia il lavoro e i rischi. In realtà, puoi e dovresti condividere le chiavi tra i due ambienti, ma devi farlo nel modo giusto per evitare conflitti di permessi.
La tecnica migliore consiste nel tenere le chiavi sul file system di Windows e creare dei collegamenti simbolici o, meglio ancora, usare un "agent bridge" che permetta a WSL di parlare con l'agente SSH di Windows. In questo modo, quando sblocchi la chiave sul tuo sistema operativo principale, è disponibile anche dentro Linux senza doverla copiare e senza rischiare che i permessi di Linux (chmod 600) entrino in conflitto con quelli di Windows. È un dettaglio tecnico sottile, ma è quello che distingue chi sa cosa sta facendo da chi sta solo cercando di far funzionare le cose "alla meno peggio".
Controllo della realtà
Smettiamola di girarci intorno: la sicurezza informatica è noiosa, ripetitiva e richiede un'attenzione maniacale ai dettagli che la maggior parte delle persone non ha voglia di applicare. Se pensi che basti generare una chiave una volta e dimenticartene, sei la vittima perfetta per il prossimo incidente di sicurezza. Non esiste una soluzione "imposta e dimentica" che sia davvero sicura.
Avere successo in questo ambito significa accettare che la comodità è il nemico della protezione. Devi spendere quei cinque minuti in più per configurare l'agente, devi sforzarti di ricordare una passphrase complessa e devi avere la disciplina di non salvare mai file sensibili dove non dovrebbero stare. Non ci sono scorciatoie. Se non sei disposto a trattare le tue chiavi SSH con lo stesso rispetto con cui tratteresti le chiavi fisiche della tua casa o della tua azienda, allora non dovresti avere la responsabilità di gestire dei server. La tecnologia ti dà gli strumenti, ma la professionalità sta nel modo in cui decidi di impugnarli ogni giorno, senza eccezioni. Nessun software o automazione ti salverà se la tua base di partenza è la pigrizia o la superficialità. La vera sicurezza non si compra, si costruisce con le buone abitudini tecniche.
