Configurare il server SSH in modo sicuro

Modulo 2: SSH e chiavi · Tempo di lettura: 12 minuti

Obiettivo della lezione: Dopo questa lezione sarà in grado di disattivare l'accesso con password e il login di root con password, di verificare quale impostazione vale davvero e di farlo senza restare chiuso fuori.

Concetti chiave: sshd, sshd_config, sshd_config.d, vale il primo valore, PasswordAuthentication, KbdInteractiveAuthentication, PermitRootLogin, AuthenticationMethods, AllowUsers, sshd -t, sshd -T, seconda sessione, cloud-init, ssh.socket

Prima di tutto la rete di sicurezza

Questa lezione chiude una porta da cui deve passare anche Lei. Un errore di battitura può significare che non riesce più a entrare. Per questo, prima di iniziare, sempre:

1. Due chiavi funzionanti (lezione 2.1), e ha verificato in una nuova finestra che l'accesso con chiave riesce.
2. Uno snapshot del Suo VPS. Con WebOké lo crea nella schermata del VPS; presso altri fornitori si chiama anche snapshot o image. Se qualcosa va storto, lo ripristina.
3. La console del Suo fornitore la conosce: da lì entra senza SSH.
4. La Sua sessione SSH attuale resta aperta fino alla fine. Una sessione in corso continua a funzionare anche se modifica le impostazioni o ricarica il servizio. Ogni modifica la verifica in una seconda finestra.

Dove si trovano le impostazioni

Il server SSH si chiama sshd. Le sue impostazioni si trovano in /etc/ssh/sshd_config. Su Debian e Ubuntu, in cima a quel file, c'è questa riga:

Include /etc/ssh/sshd_config.d/*.conf

Tutti i file con .conf nella cartella sshd_config.d vengono quindi letti prima del resto del file principale, in ordine alfabetico. È comodo: mette le Sue impostazioni in un file proprio e lascia stare il file principale, così un aggiornamento del pacchetto non tocca le Sue modifiche.

Ma c'è una conseguenza che coglie di sorpresa molte persone. In sshd_config vale questa regola: per ogni impostazione conta il primo valore che sshd incontra. Le righe successive con la stessa impostazione vengono ignorate. Chi scrive PasswordAuthentication no in fondo a sshd_config non prevale quindi su un file in sshd_config.d che dice yes.

La trappola di cloud-init

Molte image di VPS vengono configurate al primo avvio da cloud-init. A seconda di come sono impostate l'image e l'installazione, cloud-init scrive un file come /etc/ssh/sshd_config.d/50-cloud-init.conf che contiene per esempio:

PasswordAuthentication yes

Poiché quel file viene letto prima del file principale, l'accesso con password resta attivo, qualunque cosa Lei scriva in sshd_config. Quindi non lo dia per scontato, ma controlli:

root@web1:~# grep -ri passwordauthentication /etc/ssh/sshd_config /etc/ssh/sshd_config.d/
/etc/ssh/sshd_config:#PasswordAuthentication yes
/etc/ssh/sshd_config.d/50-cloud-init.conf:PasswordAuthentication yes

Due soluzioni pulite: modifichi quel file impostando no, oppure metta le Sue impostazioni in un file che viene prima in ordine alfabetico, come 00-beveiliging.conf. Un file 99-mijn.conf invece non funziona, perché a quel punto cloud-init ha già prevalso.

Le impostazioni che contano

Crei il Suo file:

root@web1:~# nano /etc/ssh/sshd_config.d/00-beveiliging.conf

con questo contenuto:

# Accesso solo con chiave
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin prohibit-password

Che cosa significa ogni riga?

• PasswordAuthentication no: il server non accetta più password. Il valore predefinito di OpenSSH è yes.
• KbdInteractiveAuthentication no: "keyboard-interactive" è un secondo modo per chiedere una password, tramite PAM. Se la lascia attiva, qualcuno può comunque tentare una password, anche se PasswordAuthentication è impostato su no. Nelle guide più vecchie questa impostazione si chiama ChallengeResponseAuthentication; da OpenSSH 8.7 è un nome alternativo obsoleto per la stessa cosa. Debian la imposta già su no per impostazione predefinita, ma la scriva comunque: così è chiaro ed è corretto anche su altri sistemi.
• PermitRootLogin prohibit-password: root può accedere, ma solo con una chiave. Da OpenSSH 7.0 è il valore predefinito. Più restrittivo è PermitRootLogin no: root non può entrare affatto via SSH, Lei accede come utente normale e usa sudo (lezione 3.2). Imposti no solo quando è certo che l'accesso con quell'utente e sudo funzionano.

Facoltativo, per chi vuole fare di più:

AllowUsers anna
AuthenticationMethods publickey

AllowUsers lascia entrare solo gli utenti indicati; qualsiasi altro nome viene rifiutato, anche se ha una chiave valida. Utile, ma non dimentichi se stesso, e non dimentichi di aggiornarlo quando aggiunge un secondo amministratore. AuthenticationMethods publickey dice in una sola riga che valgono solo le chiavi.

Verificare, applicare, controllare

Prima fa controllare il file a sshd. Questo non avvia nulla e non modifica nulla:

root@web1:~# sshd -t
root@web1:~#

Nessun output significa: nessun errore. In caso di errore di battitura vede la riga e il file. Solo allora ricarica il servizio:

root@web1:~# systemctl reload ssh

Su Debian e Ubuntu il servizio si chiama ssh, su AlmaLinux e Rocky Linux sshd.

Poi verifica quale valore vale davvero. sshd -T mostra la configurazione completa e calcolata, con tutti i file Include elaborati:

root@web1:~# sshd -T | grep -Ei 'passwordauth|kbdinteractive|permitrootlogin'
permitrootlogin without-password
passwordauthentication no
kbdinteractiveauthentication no

(without-password è il vecchio nome di prohibit-password. Le versioni di OpenSSH precedenti alla 10.1, come su Debian 13 e Ubuntu 24.04, mostrano ancora il vecchio nome; quelle più recenti mostrano prohibit-password. Il significato è lo stesso.)

E ora la cosa più importante: verifichi in una seconda finestra, mentre la prima resta aperta.

anna@laptop:~$ ssh anna@192.0.2.10
anna@web1:~$

Se funziona, provi di proposito ad accedere con una password. Il tentativo deve fallire:

anna@laptop:~$ ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no anna@192.0.2.10
anna@192.0.2.10: Permission denied (publickey).

Dopo Permission denied compare tra parentesi quali metodi di accesso il server offre ancora. Se c'è solo publickey, va bene. Se compare anche password o keyboard-interactive, da qualche parte vale ancora un altro valore: controlli di nuovo con sshd -T.

È proprio quell'elenco che controlla anche l'esercizio del corso, dall'esterno. Il Suo client SSH, a ogni connessione, chiede prima quali metodi sono ammessi, con una richiesta di tipo "none". Il server risponde con l'elenco, senza che venga provata una password o una chiave.

Ubuntu 24.04 e successivi: ssh.socket

Su Ubuntu, dalla 22.10, sulla porta 22 non è in ascolto sshd stesso ma systemd, tramite ssh.socket. Solo quando arriva una connessione systemd avvia il servizio SSH. Per le impostazioni di questa lezione non cambia nulla: systemctl reload ssh o restart ssh è sufficiente.

Cambia invece se modifica la porta o l'indirizzo di ascolto (Port, ListenAddress). Da Ubuntu 24.04 systemd legge quei valori da sshd_config, ma solo dopo:

root@web1:~# systemctl daemon-reload
root@web1:~# systemctl restart ssh.socket

Se lo dimentica, il server resta semplicemente in ascolto sulla vecchia porta. Peggio ancora: se prima imposta il firewall su una nuova porta e SSH resta sulla vecchia, resta chiuso fuori. Controlli sempre con ss -tlnp | grep ssh su quale porta il server è davvero in ascolto (lezione 5.1), e apra la nuova porta nel firewall prima di chiudere la vecchia. Se abbia senso usare un'altra porta, lo legge nella lezione 2.3.

Se qualcosa va comunque storto

Se non riesce più a entrare, apra la console del Suo fornitore, acceda come root (con la password, perché la console è una "tastiera collegata al server" e non SSH) e annulli la modifica al Suo file:

root@web1:~# mv /etc/ssh/sshd_config.d/00-beveiliging.conf /root/
root@web1:~# systemctl reload ssh

Se anche questo non riesce, ripristini lo snapshot. Con WebOké può anche impostare una nuova password di root nella schermata del VPS; altri fornitori hanno spesso un pulsante simile o una modalità di ripristino (rescue).

Su AlmaLinux e Rocky Linux

Il servizio si chiama sshd (systemctl reload sshd). Anche lì c'è un Include /etc/ssh/sshd_config.d/*.conf in cima e il sistema fornisce file propri in quella cartella; vale la stessa regola "conta il primo valore". Se modifica la porta, anche SELinux deve consentirla (semanage port -a -t ssh_port_t -p tcp 2222) e firewalld deve aprirla.

Riepilogo

• In sshd_config conta il primo valore; i file in sshd_config.d vengono letti per primi. Metta le Sue impostazioni in un file come 00-beveiliging.conf.
• Imposti PasswordAuthentication no e anche KbdInteractiveAuthentication no; root solo con una chiave (prohibit-password) o per niente (no).
• Verifichi con sshd -t prima di ricaricare e con sshd -T quale valore vale davvero; faccia attenzione a un 50-cloud-init.conf.
• Verifichi in una seconda finestra e tenga aperta la prima sessione. Conosca la console e crei prima uno snapshot.
• Su Ubuntu 24.04+ un'altra porta richiede systemctl daemon-reload e systemctl restart ssh.socket.

Quiz

Esercizio

Esercizio Z2.2: L'accesso con password è disattivato. Disattivi l'accesso con password e keyboard-interactive come in questa lezione, poi lasci controllare il programma dall'esterno. Inserisca l'indirizzo IP o il nome host del Suo server, la porta SSH (predefinita 22) e il nome utente con cui accede Lei stesso (per esempio anna, non root né un nome inventato). Il programma non effettua l'accesso: chiede soltanto, come ogni client SSH prima dell'accesso, quali metodi di accesso il Suo server offre per quell'utente. Il risultato corretto è: solo publickey.

Per approfondire

I passaggi in questi articoli valgono per la schermata del VPS di WebOké; presso altri fornitori funziona in modo simile.

• Proteggere il suo VPS: i primi cinque minuti
• Nessun accesso alla sua VPS: cosa fare?
• Snapshot e backup del suo VPS
• Manuale di sshd_config: https://man.openbsd.org/sshd_config
• Ubuntu: SSHd now uses socket-based activation: https://discourse.ubuntu.com/t/sshd-now-uses-socket-based-activation-ubuntu-22-10-and-later/30189