Ho visto questa scena ripetersi troppe volte: un professionista senior, magari un sistemista o un devops con dieci anni di esperienza, che impreca davanti al monitor perché non riesce a collegarsi a un'istanza cloud appena lanciata. Ha passato mezz'ora a lottare con i permessi dei file, convinto che il problema fosse il server, quando in realtà il disastro era iniziato molto prima, proprio sul suo desktop. Molti pensano che Generating SSH Keys on Windows sia un'operazione banale, da risolvere con un copia-incolla veloce da una guida trovata su Stack Overflow. Non lo è. Se sbagli il formato, se non gestisci correttamente l'agente o se ti affidi a software obsoleti come le vecchie versioni di PuttyGen senza capire cosa stai facendo, finirai per perdere ore di lavoro prezioso. Un errore qui significa restare chiusi fuori dai sistemi di produzione durante un'emergenza o, peggio, lasciare chiavi private sparse nel file system senza una passphrase, pronte per essere sottratte da qualsiasi malware riesca a fare breccia nel tuo perimetro locale.
L'illusione che Putty sia ancora lo standard per Generating SSH Keys on Windows
Per anni, chiunque lavorasse su sistemi Microsoft ha usato Putty. Era l'unica scelta. Oggi, continuare a usare PuttyGen come strumento principale per creare coppie di chiavi è spesso un errore che complica inutilmente la vita. Il problema non è lo strumento in sé, ma il formato del file. Putty usa il formato .ppk, che è proprietario. Se generi una chiave in questo modo e poi provi a usarla con strumenti moderni come VS Code, l'integrazione nativa di OpenSSH in Windows 11 o i terminali Linux in ambiente WSL, scoprirai che nulla funziona al primo colpo. Dovrai convertire, esportare e pregare che i permessi non saltino.
Ho assistito a un caso in cui un intero team di sviluppo ha perso una mattinata perché il lead aveva distribuito istruzioni basate su vecchi file .ppk. Quando hanno dovuto configurare l'accesso a un repository Git aziendale che accettava solo chiavi in formato OpenSSH standard, metà dei computer ha smesso di comunicare con il server. La soluzione non è scaricare l'ennesimo convertitore, ma usare gli strumenti che Microsoft ha integrato nel sistema operativo a partire dal 2018. Se apri PowerShell o il prompt dei comandi e digiti ssh-keygen, hai già tutto quello che ti serve. È lo standard universale, funziona su Linux, macOS e ora perfettamente anche qui. Usare lo strumento integrato elimina alla radice i problemi di compatibilità che affliggono chi è rimasto ancorato ai flussi di lavoro del 2010.
Gestire i permessi dei file senza impazzire tra le ACL di Windows
Qui è dove la maggior parte delle persone getta la spugna. Provi a connetterti e ricevi l'errore "Permissions for 'id_rsa' are too open". Su Linux basta un chmod 600, ma su Windows le Access Control Lists (ACL) sono una bestia completamente diversa. Ho visto utenti tentare di risolvere il problema dando il permesso "Everyone" alla cartella .ssh, pensando che aggiungere permessi avrebbe risolto il blocco. È l'esatto opposto. SSH esige che la tua chiave privata sia leggibile solo da te. Se il sistema rileva che altri utenti o gruppi hanno accesso a quel file, rifiuta la connessione per sicurezza.
Invece di combattere con l'interfaccia grafica delle proprietà del file, che è un labirinto di ereditarietà e permessi speciali, devi agire con precisione chirurgica. Se la tua chiave si trova in %userprofile%\.ssh\, devi assicurarti che l'ereditarietà sia disabilitata e che solo il tuo utente specifico abbia il controllo completo. Non il gruppo Administrators, non il gruppo System. Solo tu. Ho visto amministratori di rete passare ore a resettare server convinti che il problema fosse lato server, quando il client Windows stava semplicemente proteggendo l'utente da se stesso rifiutandosi di usare una chiave non protetta. La realtà è che se non capisci come Windows gestisce l'identità dell'utente rispetto al file system, passerai metà della tua carriera a digitare password manualmente perché le tue chiavi non vengono accettate.
Il rischio concreto di ignorare la Passphrase durante Generating SSH Keys on Windows
C'è una tentazione fortissima quando si crea una chiave: premere invio due volte e lasciare la passphrase vuota. Sembra una comodità. Niente da digitare ogni volta che ti colleghi, automazione totale. Ma questo è un errore che può costare il posto di lavoro o, per un'azienda, una violazione catastrofica dei dati. Se la tua chiave privata non ha una passphrase, chiunque ottenga l'accesso al tuo laptop, anche solo per cinque minuti, o riesca a leggere il contenuto del tuo disco, possiede le chiavi del tuo regno. Non c'è un secondo fattore. Non c'è protezione.
Dalla mia esperienza, la scusa principale per non usare una passphrase è la pigrizia, mascherata da necessità di efficienza. Ma oggi questo non ha senso. Windows dispone di un servizio chiamato "OpenSSH Authentication Agent" che può essere impostato su avvio automatico. Una volta configurato, inserisci la passphrase una sola volta all'avvio della sessione e l'agente la tiene in memoria per te. È il compromesso perfetto tra sicurezza e usabilità. Chi sceglie di generare chiavi "nude" sta scommettendo sulla sicurezza fisica del proprio ufficio o della propria abitazione, una scommessa che prima o poi si perde. Ricordo un consulente che perse il suo portatile in treno; non aveva passphrase sulle chiavi. Prima ancora che arrivasse a casa per cambiare le password, i log dei server mostravano già accessi non autorizzati da IP sconosciuti. La chiave privata è la tua identità digitale; trattarla con leggerezza è pura negligenza professionale.
Scegliere l'algoritmo sbagliato per una falsa sensazione di sicurezza
Molte guide online suggeriscono ancora di creare chiavi RSA a 2048 bit. Sebbene non siano ancora "rotte" nel senso letterale del termine, sono pesanti, lente e meno sicure rispetto alle alternative moderne. Molti utenti pensano che RSA sia lo standard perché è il più vecchio, ma in un ambiente Windows moderno, dovresti puntare su ED25519. Le chiavi generate con questo algoritmo sono molto più corte, il che le rende più facili da gestire e meno inclini a errori di formattazione durante il copia-incolla nei pannelli di controllo cloud.
La superiorità di ED25519 rispetto a RSA
Le chiavi RSA si basano sulla difficoltà di fattorizzare numeri primi molto grandi. Più aumenta la potenza di calcolo, più devono diventare lunghe queste chiavi per restare sicure. Una chiave ED25519, invece, offre una sicurezza equivalente o superiore a una RSA a 3072 bit pur essendo lunga solo una frazione. Inoltre, è più resistente agli attacchi di tipo side-channel. Ho visto sistemi legacy rifiutare connessioni da nuove chiavi RSA perché usavano algoritmi di firma obsoleti (come SHA-1) che le versioni recenti di OpenSSH su Windows disabilitano di default per motivi di sicurezza. Passare a ED25519 risolve questi problemi di compatibilità futura in un colpo solo. Non c'è motivo di usare RSA a meno che tu non debba connetterti a un hardware di rete del 2005 che non riceve aggiornamenti da allora. In quel caso, il tuo problema non è la chiave SSH, ma un'infrastruttura che è un colabrodo.
Confronto tra l'approccio amatoriale e quello professionale
Per capire meglio l'impatto di queste scelte, analizziamo come si comporta un utente inesperto rispetto a un professionista preparato in uno scenario reale di configurazione di una nuova workstation Windows.
L'utente inesperto inizia scaricando un pacchetto software esterno, spesso senza verificarne l'integrità. Crea una chiave RSA a 2048 bit senza passphrase, perché vuole che tutto sia veloce. Salva il file .ppk sul desktop o in una cartella generica. Quando prova a connettersi a un server Linux, si rende conto che il server vuole una chiave pubblica in formato OpenSSH. Allora cerca un convertitore online, rischiando di caricare la sua chiave privata su un sito web sconosciuto. Una volta ottenuta la stringa, la incolla nel file authorized_keys del server. Se tutto va bene, si connette. Ma se deve usare quella stessa chiave per un tunnel SSH in un database manager o per distribuire codice, iniziano i conflitti tra formati. Se perde il PC, chiunque lo trovi entra nei suoi server. Se il server viene aggiornato e smette di accettare firme RSA deboli, si ritrova tagliato fuori senza capire perché.
Il professionista agisce in modo diverso. Apre il terminale nativo di Windows. Digita il comando per creare una chiave ED25519, inserisce una passphrase robusta e salva il file nella posizione standard. Abilita il servizio dell'agente SSH di Windows tramite PowerShell in modo che parta a ogni avvio del sistema. Aggiunge la chiave all'agente una volta per tutte. Quando deve configurare un nuovo server, usa cat ~/.ssh/id_ed25519.pub e incolla la stringa. La connessione è istantanea, sicura e protetta. Se deve usare VS Code o WSL, tutto funziona senza configurazioni aggiuntive perché tutti questi strumenti leggono nativamente dalla stessa posizione e dallo stesso agente. In caso di smarrimento del dispositivo, la passphrase protegge l'accesso, dando il tempo di revocare la chiave pubblica dai server. La differenza tra i due approcci non è solo nella sicurezza, ma nella quantità di attrito quotidiano. Il professionista non pensa più alla connessione, la usa e basta. L'amatore combatte contro la tecnologia ogni volta che qualcosa cambia.
Evitare la trappola del copia-incolla corrotto nel terminale
Un errore banale, ma estremamente costoso in termini di tempo, riguarda il modo in cui la chiave pubblica viene trasferita da Windows al server remoto. Il terminale di Windows, specialmente nelle versioni meno recenti o se non configurato bene, può inserire dei caratteri di a capo (\n) o spazi nascosti quando si copia una lunga stringa di testo. Se la chiave pubblica nel file authorized_keys del server non è su un'unica riga continua, la connessione fallirà sistematicamente.
Ho visto persone passare ore a controllare i log di /var/log/auth.log cercando di capire perché il server rifiutasse la chiave, solo per scoprire che c'era uno spazio di troppo alla fine della stringa o che la chiave era stata spezzata su due righe dal blocco note di Windows. Per evitare questo, non dovresti mai aprire la tua chiave pubblica con programmi di videoscrittura pesanti. Usa il comando Get-Content in PowerShell o direttamente type nel prompt dei comandi per visualizzare il contenuto e copiarlo con cautela. Ancora meglio, se hai accesso tramite password inizialmente, usa strumenti che gestiscono il trasferimento in modo pulito. Non fidarti mai di quello che vedi a schermo se hai fatto un copia-incolla da un'interfaccia web che potrebbe aver riformattato il testo. Un singolo carattere invisibile renderà l'intera coppia di chiavi inutile, portandoti a credere che il problema sia l'algoritmo o il firewall, quando è solo un refuso digitale.
Gestione dei conflitti tra OpenSSH di Windows e installazioni terze
Un altro punto di attrito frequente accade quando sul sistema convivono più versioni di SSH. Magari hai installato Git for Windows, che porta con sé la sua versione di OpenSSH, e contemporaneamente hai attivato la funzione opzionale di Windows per SSH. Se non stai attento a quale binario viene richiamato per primo nel tuo PATH, potresti finire per generare chiavi con uno strumento e cercare di gestirle con un agente che appartiene all'altro.
Mi è capitato di fare consulenza per un'azienda dove gli sviluppatori riuscivano a connettersi da terminale, ma i loro script di automazione fallivano miseramente. Il motivo? Il terminale usava la versione di SSH di Git, mentre gli script di sistema usavano quella nativa di Microsoft. Le due versioni cercavano le chiavi in posti leggermente diversi e avevano configurazioni dell'agente separate. La soluzione qui è la coerenza. Scegli una strada e assicurati che sia l'unica nel tuo percorso di sistema. Nel 2026, la raccomandazione è quasi sempre quella di utilizzare la versione nativa fornita da Microsoft, poiché è quella meglio integrata con le funzionalità di sicurezza del sistema operativo e con il Windows Terminal. Eliminare la ridondanza non è solo una questione di pulizia, è l'unico modo per avere un ambiente di sviluppo prevedibile dove non devi chiederti ogni volta "quale ssh sto usando?".
Controllo della realtà
Smettiamola di raccontarci che gli strumenti moderni hanno reso tutto automatico. La verità è che il passaggio a un'infrastruttura sicura su Windows richiede una comprensione manuale che molti non vogliono acquisire. Non esiste un pulsante "fai tutto tu" che sia realmente affidabile per un uso professionale. Se non hai voglia di imparare come funziona il file system di Windows, come si gestisce un servizio di background per l'agente SSH e perché un algoritmo sia preferibile a un altro, continuerai a essere vittima di errori stupidi e perdite di tempo imbarazzanti.
Il successo in questo ambito non dipende dal software più costoso, ma dalla disciplina di seguire un metodo standardizzato. Non importa quanto sia potente il tuo computer o quanto sia veloce la tua connessione fibra: se la tua configurazione di base è fragile, la tua intera giornata lavorativa poggerà su fondamenta di sabbia. Prendi mezz'ora, pulisci le vecchie chiavi, disinstalla i software inutili, imposta correttamente l'agente di Windows e usa una passphrase vera. È un investimento che non ti darà una gratificazione immediata, ma ti risparmierà quella telefonata nel cuore della notte in cui scopri che non puoi intervenire su un server che sta crollando perché il tuo client SSH ha deciso di non collaborare. Non c'è una via di mezzo tra essere sicuri ed essere fortunati; e nel settore tecnologico, la fortuna ha la brutta abitudine di finire nel momento peggiore possibile.
