Generatore di Chiavi SSH

RSA a 2048 bit soddisfa gli attuali standard di sicurezza ed è approvato dal NIST almeno fino al 2030. RSA a 4096 bit offre un margine di sicurezza maggiore per chiavi che saranno in uso per molti anni, ma è significativamente più lento nelle operazioni di handshake (circa 4 volte più lento rispetto a 2048 bit). Per la maggior parte dei casi d'uso — accesso al server, GitHub/GitLab, pipeline CI/CD — 2048 bit è sufficiente. Per le chiavi utilizzate in ambienti ad alta sicurezza o che devono restare in uso per oltre 10 anni, usa 4096 bit. Per la migliore combinazione di velocità e sicurezza, usa invece Ed25519.

Una passphrase cifra il tuo file della chiave privata in modo che, anche se qualcuno ottiene il file, non possa usarlo senza la passphrase. Quando usi la chiave, il tuo client SSH ti chiede la passphrase per decifrarla (ssh-agent può memorizzare la chiave decifrata in modo da non essere interrogato ripetutamente). Per le chiavi rivolte all'utente (dal tuo laptop ai tuoi server), usa una passphrase: fornisce una protezione critica se la tua macchina viene persa o rubata. Per le chiavi di deployment automatizzate CI/CD che funzionano senza interazione umana, le chiavi protette da passphrase sono impraticabili e il file della chiave deve essere protetto con altri mezzi (permessi del file, sistemi di gestione dei segreti).

Copia il contenuto della chiave pubblica (che inizia con "ssh-rsa" o "ssh-ed25519") e aggiungilo al file ~/.ssh/authorized_keys sul tuo server. Una chiave pubblica per riga. Se la directory non esiste: mkdir -p ~/.ssh && chmod 700 ~/.ssh. Imposta i permessi corretti: chmod 600 ~/.ssh/authorized_keys. Il metodo più veloce dalla tua macchina locale: ssh-copy-id user@hostname (usando la tua password per questa configurazione una tantissima). Dopodiché, SSH userà la tua chiave automaticamente. La tua chiave privata rimane solo sulla tua macchina locale e non viene mai caricata da nessuna parte.

Il commento è un'etichetta incorporata nella chiave pubblica dopo i dati della chiave (ad esempio ssh-ed25519 AAAA... user@laptop). Non ha alcun effetto sull'autenticazione — è puramente descrittivo. Usalo per identificare l'origine della chiave quando controlli authorized_keys su un server: chi ha creato questa chiave, da quale macchina e per quale scopo. Formati comuni: user@hostname (predefinito), il tuo indirizzo email o un'etichetta descrittiva come "ci-deploy-prod-2026". Quando hai più chiavi in authorized_keys, un commento significativo è il modo per sapere quale chiave revocare se qualcosa va storto.

L'impronta digitale (fingerprint) è un hash SHA-256 della chiave pubblica, visualizzato in formato Base64 (ad esempio SHA256:abc123...). È un modo compatto per identificare e verificare una specifica chiave. Quando ti connetti per la prima volta a un server con SSH, il server ti mostra la sua impronta digitale della chiave host — la verifichi per confermare che ti stai connettendo al server giusto. Quando carichi una chiave pubblica su GitHub, GitLab o altri servizi, loro ti mostrano l'impronta digitale. Se l'impronta digitale corrisponde a quella mostrata da questo strumento, la chiave è stata caricata correttamente. Puoi anche eseguire ssh-keygen -l -f ~/.ssh/id_ed25519 sulla tua macchina per verificare le impronte digitali localmente.

Sì. Tutti i processi di generazione delle chiavi utilizzano la Web Crypto API, una API nativa del browser che fornisce operazioni crittograficamente sicure supportate dalla sorgente di entropia del sistema operativo. La generazione dei numeri casuali utilizza crypto.getRandomValues(), non il non sicuro Math.random(). Le chiavi generate sono equivalenti in termini di sicurezza a quelle prodotte da ssh-keygen sulla riga di comando. Nulla viene inviato a nessun server — la coppia di chiavi esiste solo nella tua sessione del browser.

Non sostituire mai i tuoi esistenti authorized_keys — aggiungi la tua nuova chiave pubblica come voce aggiuntiva. Quindi apri una seconda sessione SSH (senza chiudere quella attuale) per testare la nuova chiave. Solo dopo aver confermato che la nuova chiave funziona, dovresti rimuovere le vecchie chiavi o cambiare la tua politica di password. Se rimani chiuso fuori, avrai bisogno di accesso alla console del server (i fornitori cloud chiamano questo "emergency console" o "rescue mode") per modificare manualmente authorized_keys.