Accesso SSH con chiave su una VPS Ubuntu: guida completa con PuTTYgen e WinSCP

Accesso SSH con chiave su una VPS Ubuntu: guida completa con PuTTYgen e WinSCP

Pochi minuti dopo che una VPS va online, la porta 22 comincia a ricevere tentativi di accesso automatici: script che provano root con migliaia di password comuni. Una password lunga e casuale rende il successo di questi attacchi molto improbabile e Fail2ban blocca chi insiste, ma la password resta comunque una porta aperta.

Con una chiave SSH il discorso cambia. Si crea una coppia di file collegati: la chiave pubblica, che si mette sul server e non è un segreto, e la chiave privata, che resta solo sul tuo PC e non viene mai inviata a nessuno. Il server verifica che tu possieda la privata senza che questa viaggi in rete. Una volta disattivate le password, un bot non ha più niente da indovinare.

In questa guida configuriamo tutto da Windows con PuTTYgen, WinSCP e PuTTY, su un server Ubuntu.

Cosa serve

• Una VPS Ubuntu con accesso come root o come utente con sudo.
• Un PC Windows con PuTTYgen e PuTTY (si installano con il pacchetto ufficiale di PuTTY) e WinSCP.
• PuTTY dalla versione 0.75 in poi, altrimenti non legge le chiavi nel formato nuovo (ne parliamo negli errori comuni).
• L’accesso alla console web (VNC) del provider, che è il tuo ripiego se qualcosa va storto.
• Un gestore di password per conservare il backup della chiave.

Regola d’oro: non chiudere mai la sessione SSH attuale finché non hai verificato che la chiave funziona da una nuova connessione.

1. Generare la chiave

1. Apri PuTTYgen.
2. In basso, in Type of key to generate, scegli EdDSA e assicurati che la curva sia Ed25519.
3. Premi Generate e muovi il mouse nell’area vuota finché la barra non si completa.
4. Scrivi una passphrase nei campi Key passphrase e Confirm passphrase. Protegge il file della chiave privata: se qualcuno lo copia, senza passphrase non può usarlo.

Non chiudere PuTTYgen: la chiave privata esiste ancora solo lì dentro finché non la salvi.

2. Salvare la chiave privata e fare il backup

1. Premi Save private key e salva il file, per esempio come server.ppk, in una cartella tua, come C:\Users\IL_TUO_NOME\.ssh\. Non sul desktop e non in cartelle sincronizzate con servizi cloud.
2. Per il backup, vai su Conversions → Export OpenSSH key e salva il file in una cartella temporanea.
3. Conserva il contenuto del backup nel tuo gestore di password (una nota sicura va bene), insieme alla passphrase in un campo separato. Se perdi il PC, la ritrovi lì.
4. Cancella il file di backup dal disco e svuota il cestino.

Da PuTTYgen ti serve anche la chiave pubblica: è la riga nel riquadro in alto, intitolata Public key for pasting into OpenSSH authorized_keys file. Comincia con ssh-ed25519 ed è su una sola riga.

Attenzione al pulsante Save public key. Non usarlo per questo scopo: produce un file in formato diverso (con intestazioni ---- BEGIN SSH2 PUBLIC KEY ----) che il server non accetta in authorized_keys. Va copiata a mano la riga del riquadro: clicca dentro, premi Ctrl+A e poi Ctrl+C.

3. Installare la chiave pubblica sul server

Collegati al server con la password e, nella sessione già aperta, crea la cartella e il file (se sei root, ~ è /root):

mkdir -p ~/.ssh
chmod 700 ~/.ssh
nano ~/.ssh/authorized_keys

Incolla la riga pubblica intera e su una sola riga. Se il file contiene già altre chiavi, aggiungi la tua in fondo senza toccarle. Salva con Ctrl+O, Invio, esci con Ctrl+X. Poi imposta i permessi e controlla:

chmod 600 ~/.ssh/authorized_keys
ssh-keygen -lf ~/.ssh/authorized_keys

Il secondo comando mostra l’impronta (fingerprint) della chiave installata. Deve coincidere con quella che PuTTYgen mostra nel campo Key fingerprint. Se vedi più righe, controlla che non ci siano chiavi vecchie che non usi più, e cancellale.

4. Provare l’accesso con la chiave

Senza chiudere la sessione attuale:

1. In WinSCP crea una nuova connessione: protocollo SFTP, host del server, utente (root o il tuo), password vuota.
2. Apri Avanzate → SSH → Autenticazione e in File chiave privata scegli il tuo .ppk.
3. Connetti. WinSCP deve chiederti la passphrase della chiave, non la password del server.

Dalla sessione vecchia puoi confermare con quale metodo sei entrato:

sudo journalctl -u ssh --since '10 min ago' | grep Accepted

Se vedi Accepted publickey for ..., la chiave funziona. Se vedi Accepted password, sei entrato con la password: non andare avanti e controlla la configurazione di WinSCP.

Finora non hai cambiato nulla sul server: l’accesso con la password è ancora attivo ed è la tua rete di sicurezza. Non disattivarlo finché non hai verificato che l’accesso con la chiave funziona davvero, cioè con Accepted publickey nel log e una nuova connessione riuscita.

5. Disattivare le password

Disattiva le password solo dopo aver verificato, al passo 4, che l’accesso con la chiave funziona: fino ad allora lasciale attive, perché sono la tua via di rientro. Questo è il passaggio che richiede più attenzione, perché ci sono due trappole.

Prima trappola: i file di cloud-init. Su molte immagini Ubuntu dei provider, un file in /etc/ssh/sshd_config.d/ (di solito 50-cloud-init.conf) imposta PasswordAuthentication yes. In sshd vince la prima impostazione trovata e i file si leggono in ordine alfabetico, quindi quel file prevale sulle modifiche che fai in sshd_config. Controlla cosa c’è:

sudo grep -ri 'PasswordAuthentication' /etc/ssh/sshd_config /etc/ssh/sshd_config.d/

Per prevalere su tutti, crea un file con un nome che viene letto per primo, come 00-hardening.conf.

Seconda trappola: la cartella. Quella del server si chiama sshd_config.d (con la d dopo ssh). Esiste anche ssh_config.d, che appartiene al client SSH: un file messo lì non ha nessun effetto sul server. Creando il file dal terminale elimini il rischio di sbagliare cartella:

sudo tee /etc/ssh/sshd_config.d/00-hardening.conf > /dev/null <<'EOF'
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin prohibit-password
EOF

• PasswordAuthentication no: disattiva l’accesso con la password.
• KbdInteractiveAuthentication no: chiude la via delle password tramite PAM, che altrimenti può restare aperta.
• PermitRootLogin prohibit-password: consente a root di entrare solo con la chiave.

Prima di applicare, verifica la sintassi. Se sshd -t non stampa nulla, il file è valido:

sudo sshd -t && sudo systemctl reload ssh
sudo sshd -T | grep -Ei 'passwordauthentication|kbdinteractiveauthentication|permitrootlogin'

Il risultato giusto è passwordauthentication no, kbdinteractiveauthentication no e permitrootlogin prohibit-password (su versioni più vecchie di OpenSSH compare come without-password, che è lo stesso). Se leggi ancora yes, un altro file sta prevalendo: il grep di prima ti dice quale.

6. Verifica finale

Sempre con la sessione vecchia ancora aperta:

1. Con la chiave deve entrare. Apri un’altra connessione con il .ppk: deve funzionare e chiederti la passphrase.
2. Senza chiave deve rifiutare. Dal Prompt dei comandi di Windows:

ssh -o PubkeyAuthentication=no utente@IP_DEL_SERVER

La prima volta il client ti chiede di confermare l’impronta del server: per essere sicuro che sia il tuo, confrontala con quella del server (ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub). Il risultato giusto è che il server non ti chiede la password: risponde Permission denied (publickey) oppure chiude direttamente la connessione.

Solo ora puoi chiudere la sessione vecchia.

Se usi un utente diverso da root

La chiave va installata per ogni utente con cui ti colleghi. Se accedi anche come nomeutente, per esempio, serve il file /home/nomeutente/.ssh/authorized_keys, con la stessa riga pubblica e i permessi giusti:

sudo mkdir -p /home/nomeutente/.ssh
sudo nano /home/nomeutente/.ssh/authorized_keys
sudo chown -R nomeutente:nomeutente /home/nomeutente/.ssh
sudo chmod 700 /home/nomeutente/.ssh
sudo chmod 600 /home/nomeutente/.ssh/authorized_keys

Se sbagli i proprietari o i permessi, sshd ignora il file e la chiave non viene accettata, senza segnalare errori evidenti.

Gli errori che si incontrano più spesso

• Permission denied (publickey) dopo il passo 3: quasi sempre la riga in authorized_keys è stata spezzata o copiata male, hai usato Save public key invece della riga del riquadro, i permessi di ~/.ssh sono troppo ampi, oppure hai installato la chiave per un utente e ti colleghi con un altro. Per i dettagli leggi sudo journalctl -u ssh -n 30.
• Le password non si disattivano (sshd -T mostra ancora yes): il file è nella cartella sbagliata (ssh_config.d invece di sshd_config.d), il nome non finisce in .conf, oppure un altro file letto prima imposta il contrario.
• PuTTY key format too new: il tuo .ppk è nel formato 3, che PuTTY legge solo dalla versione 0.75. WinSCP e altri client possono funzionare lo stesso. Aggiorna PuTTY con il programma di installazione ufficiale, oppure risalva la chiave nel formato 2 da PuTTYgen (Key → Parameters for saving key files); l’aggiornamento è la strada migliore, perché il formato 2 protegge la passphrase in modo più debole.
• PuTTY non usa la chiave: nelle impostazioni della sessione, in Connection → SSH → Auth → Credentials, indica il file .ppk e poi salva la sessione.

Se ti chiudi fuori

Se la sessione vecchia è ancora aperta, annulla subito:

sudo rm /etc/ssh/sshd_config.d/00-hardening.conf
sudo systemctl reload ssh

Se l’hai chiusa, entra dalla console web (VNC) del provider con la password di root ed esegui gli stessi due comandi. La console non passa da SSH, quindi funziona anche con le password SSH disattivate. Conviene provarla prima di disattivare le password: di solito usa il layout di tastiera americano, quindi una password con molti simboli può essere difficile da digitare.

In pratica, il ripiego vale quanto la sicurezza dell’account del provider: proteggilo con una password lunga e la verifica in due passaggi.

Fail2ban resta utile

Disattivare le password non rende inutile Fail2ban. I bot continueranno a bussare alla porta 22 e la jail sshd li blocca prima che consumino risorse. Con le password spente il rischio non è più l’indovinare un accesso, ma il semplice carico che i tentativi generano.

Checklist finale

• Chiave Ed25519 generata con passphrase.
• File .ppk salvato in una cartella sicura, backup nel gestore di password, file temporanei cancellati.
• Riga pubblica in authorized_keys (una riga sola), permessi 700 e 600.
• Accesso con chiave provato da una nuova connessione, con Accepted publickey nel log.
• 00-hardening.conf in /etc/ssh/sshd_config.d/ e sshd -T con le password su no.
• Prova senza chiave: nessuna richiesta di password.
• Console VNC del provider provata e password di root salvata.
• Stessa procedura ripetuta su ogni server e per ogni utente che accede.

Conclusione

Il lavoro richiede poco più di mezz’ora e si fa una volta sola. Il vantaggio non è solo la sicurezza: dopo la configurazione l’accesso è anche più comodo, perché non devi digitare la password del server ogni volta. E per chi gestisce più VPS, una sola chiave può servire su tutte, purché sia protetta da una buona passphrase e salvata con cura.