OpenSSH: hardening senza perdere l’accesso amministrativo

L’hardening di SSH è una modifica al percorso di amministrazione. La misura di successo è una configurazione verificata, con accessi autorizzati funzionanti e un recupero praticabile. Una lista di direttive copiata senza conoscere Include, Match e autenticazione distribuita può bloccare gli operatori.

Inventario delle dipendenze

Prima di modificare il servizio, elencare utenti umani, automazioni, trasferimenti SFTP, bastion e sistemi di backup. Distinguere una chiave personale da una credenziale usata da un job. Registrare versione e pacchetto OpenSSH, percorso della configurazione e unità di servizio: sulle distribuzioni Linux i dettagli possono differire.

Predisporre un accesso fuori banda e tenere aperta una sessione amministrativa già autenticata. In un laboratorio eseguire prima l’intera procedura, incluso recupero della configurazione precedente. Se non esiste un canale di recupero verificato, pianificare la modifica con chi gestisce la console.

Una base per accessi a chiave

Il manuale sshd_config documenta le direttive e la loro interazione. Per un servizio destinato esclusivamente ad amministratori con chiavi già distribuite, questo è un frammento da integrare, non una configurazione universale:

PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
AuthenticationMethods publickey
AllowGroups ssh-admins

Creare e verificare il gruppo ssh-admins prima di applicare la restrizione. Disabilitare keyboard-interactive esclude quel percorso: non usare questo frammento se una soluzione MFA basata su PAM lo richiede. AuthenticationMethods publickey impone la chiave come metodo; chiave più secondo fattore richiede un progetto e una configurazione diversi.

Evidenze riproducibili: leggere la configurazione effettiva

Per molte direttive sshd usa il primo valore ottenuto. Include e sezioni Match rendono insufficiente controllare una sola riga. Il manuale sshd descrive -t per la validazione e -T, con -C, per esaminare la configurazione nel contesto di una connessione.

sudo sshd -t
sudo sshd -T -C user=alice,host=client.example,addr=192.0.2.10

alice, client.example e 192.0.2.10 sono valori di esempio: sostituirli con il contesto reale. Il comando -T non prova che l’utente possa accedere e non collauda l’intero percorso PAM, autorizzazioni dei file o rete. Salvare l’output pertinente senza raccogliere inutilmente informazioni sugli utenti.

Collaudo e rollback

1. Salvare la configurazione precedente e validare quella nuova.
2. Applicare il reload con il comando della distribuzione solo dopo la validazione.
3. Aprire una nuova sessione con un utente consentito e verificare i privilegi necessari.
4. Provare un utente non consentito e un metodo che deve essere rifiutato.
5. Verificare automazioni e trasferimenti prima di chiudere la sessione di recupero.

Un test negativo deve osservare il rifiuto atteso e i relativi log. “Non riesco a collegarmi” può dipendere da firewall, DNS o host key e non dimostra che la direttiva abbia funzionato. Il rollback deve ripristinare la configurazione e il servizio, poi essere seguito da un nuovo accesso.

Ridurre i privilegi delle automazioni

Le opzioni di authorized_keys, come restrict e comandi forzati, possono circoscrivere una chiave secondo il manuale. Valutare ogni automazione separatamente. Limitare il forwarding non contiene un utente che conserva una shell e può eseguire propri strumenti: non presentare quella sola direttiva come isolamento.

Documentare proprietario e scadenza delle chiavi, gestione delle revoche e controllo delle host key. Spostare SSH su una porta diversa può cambiare il rumore osservato, ma non sostituisce autenticazione, patching e restrizione dell’esposizione di rete.

Fonti essenziali

Riferimenti primari consultati il 3 ottobre 2026. Le procedure di analisi e gli scenari di laboratorio sono proposte editoriali: vanno adattati alla telemetria e alle versioni installate.

• OpenBSD — sshd_config
• OpenBSD — sshd e authorized_keys