Hardening SSH 2026: Setup Completo

Introduzione: Perché l'Hardening SSH È Più Critico che Mai

SSH è il protocollo che tiene in piedi l'amministrazione remota di praticamente ogni server Linux al mondo. E proprio per questo, è anche uno dei bersagli più martellati dagli attaccanti. Un server Linux medio riceve centinaia di tentativi di brute force SSH al giorno — non alla settimana, al giorno. Durante attacchi mirati, quel numero può salire a migliaia in poche ore. Se avete mai dato un'occhiata ai log di un server appena messo online, sapete di cosa parlo.

Ma nel 2026 il panorama delle minacce va ben oltre il brute force. L'incidente della backdoor in XZ Utils di inizio 2024 ci ha fatto venire i brividi: codice malevolo infiltrato in un componente fondamentale di Linux, con la possibilità di esecuzione remota di codice proprio attraverso SSH. E il kernel Linux ha registrato 5.530 CVE nel solo 2025, un incremento del 28% rispetto all'anno prima — parliamo di 8-9 nuove vulnerabilità del kernel ogni singolo giorno.

Insomma, il contesto è cambiato parecchio.

OpenSSH stesso ha subito trasformazioni radicali: la versione 10.0 (aprile 2025) ha introdotto la crittografia post-quantum come default, e la 10.1 (ottobre 2025) ha aggiunto avvisi per chi usa ancora algoritmi vulnerabili. Se la vostra configurazione SSH è ferma a due anni fa, state lasciando la porta aperta — e non in senso figurato.

In questo articolo approfondiamo ogni aspetto dell'hardening SSH moderno: dalla crittografia post-quantum all'autenticazione con chiavi hardware FIDO2, dai certificati SSH alla difesa proattiva con CrowdSec, passando per la configurazione ottimale di sshd_config e l'architettura bastion host. Tutto quello che vi serve per blindare i vostri server nel 2026.

OpenSSH 10.0 e 10.1: Le Novità che Cambiano le Regole del Gioco

Prima di entrare nelle configurazioni pratiche, vale la pena capire cosa è cambiato nelle ultime versioni di OpenSSH. Le release del 2025 rappresentano, onestamente, il cambiamento più significativo nella sicurezza SSH degli ultimi dieci anni.

OpenSSH 10.0 (Aprile 2025)

La novità principale è l'adozione di mlkem768x25519-sha256 come algoritmo di key exchange predefinito. Si tratta di un algoritmo ibrido che combina ML-KEM (un meccanismo di incapsulamento chiave standardizzato dal NIST, pensato per resistere agli attacchi quantistici) con X25519 (curva ellittica classica). Il risultato? Protezione sia contro computer classici che quantistici.

Altre modifiche cruciali:

Rimozione completa di DSA: l'algoritmo di firma DSA, deprecato dal 2015, è stato definitivamente eliminato. Era ora
Nuovo binario sshd-auth: il codice di autenticazione pre-login è stato separato in un binario dedicato per ridurre la superficie di attacco
AES-GCM prioritario: AES-GCM viene ora preferito ad AES-CTR, con ChaCha20/Poly1305 che mantiene la massima priorità
Sostituzione di Diffie-Hellman a campo finito: i metodi DH classici (modp) sono sostituiti da ECDH come default
Match version e Match sessiontype: nuove direttive di configurazione per un controllo più granulare

OpenSSH 10.1 (Ottobre 2025)

La 10.1 ha portato cambiamenti altrettanto importanti:

Avviso per algoritmi non post-quantum: quando viene negoziato un key exchange non resistente al quantum computing, SSH mostra un avviso. Potete controllarlo tramite la nuova opzione WarnWeakCrypto
Fix di sicurezza critico: corretta una vulnerabilità che permetteva la manipolazione di comandi shell tramite caratteri speciali nei nomi utente con ProxyCommand
Spostamento dei socket dell'agent: i socket listener passano da /tmp a ~/.ssh/agent, impedendo a processi con accesso limitato al filesystem di sfruttare le chiavi
Supporto Ed25519 in token PKCS#11: finalmente il supporto per chiavi Ed25519 conservate in token hardware
Rimozione chiavi XMSS sperimentali

Il messaggio è chiaro: OpenSSH si sta muovendo aggressivamente verso la crittografia post-quantum. Chi non aggiorna la propria configurazione riceverà avvisi crescenti e, in futuro, perderà compatibilità.

Crittografia Post-Quantum: Proteggere le Sessioni dal Futuro

Perché preoccuparsi della crittografia post-quantum adesso, se i computer quantistici capaci di rompere la crittografia classica sono ancora lontani 5-20 anni? La risposta è in due parole: "store now, decrypt later".

Attaccanti sofisticati — e servizi di intelligence statali — stanno già registrando traffico SSH crittografato con l'intenzione di decifrarlo quando i computer quantistici saranno disponibili. Pensateci un attimo: se gestite server con dati sensibili a lungo termine (proprietà intellettuale, segreti industriali, dati governativi), il traffico che intercettano oggi potrebbe essere letto tra dieci anni. Non è fantascienza, è pianificazione strategica.

Configurazione del Key Exchange Post-Quantum

Con OpenSSH 10.0+, la crittografia post-quantum è già attiva di default. Ma se gestite server con versioni precedenti o volete una configurazione esplicita (e personalmente vi consiglio di essere espliciti), ecco come procedere.

Configurazione lato server in /etc/ssh/sshd_config:

# Algoritmi di key exchange con priorità post-quantum
# mlkem768x25519-sha256: ibrido ML-KEM + X25519 (NIST standardizzato)
# sntrup761x25519-sha512: ibrido NTRU Prime + X25519
# I rimanenti sono fallback classici sicuri

KexAlgorithms mlkem768x25519-sha256,[email protected],curve25519-sha256,[email protected]

# Cifratura: ChaCha20 e AES-GCM
Ciphers [email protected],[email protected],[email protected]

# Algoritmi di MAC (Message Authentication Code)
MACs [email protected],[email protected]

# Algoritmi per le chiavi host
HostKeyAlgorithms ssh-ed25519,rsa-sha2-512,rsa-sha2-256

Configurazione corrispondente lato client in ~/.ssh/config o /etc/ssh/ssh_config:

Host *
    KexAlgorithms mlkem768x25519-sha256,[email protected],curve25519-sha256
    Ciphers [email protected],[email protected],[email protected]
    MACs [email protected],[email protected]
    HostKeyAlgorithms ssh-ed25519,rsa-sha2-512,rsa-sha2-256
    PubkeyAcceptedAlgorithms ssh-ed25519,rsa-sha2-512,rsa-sha2-256

Per verificare che la connessione utilizzi effettivamente un algoritmo post-quantum:

# Connessione con verbose per vedere l'algoritmo negoziato
ssh -vvv user@server 2>&1 | grep "kex:"

# Output atteso:
# debug1: kex: algorithm: mlkem768x25519-sha256
# oppure
# debug1: kex: algorithm: [email protected]

Un test rapido con un algoritmo specifico:

# Forzare l'uso di un singolo algoritmo post-quantum
ssh -o [email protected] user@server

Da settembre 2025, anche GitHub ha adottato sntrup761x25519-sha512 per proteggere l'accesso SSH ai repository Git. Quando un'organizzazione delle dimensioni di GitHub considera la crittografia post-quantum una priorità, beh, è un segnale che dovreste prendere sul serio.

Autenticazione a Chiave Pubblica: La Base Fondamentale

Disabilitare l'autenticazione tramite password è il singolo cambiamento che elimina il 99% degli attacchi automatizzati al vostro server. Punto. Nel 2026, se avete ancora PasswordAuthentication yes su un server esposto a Internet, state praticamente invitando gli attaccanti a entrare.

Generazione Chiavi Ed25519

L'algoritmo Ed25519 è lo standard raccomandato, e per buoni motivi. Rispetto a RSA offre chiavi più corte, firme più veloci e una sicurezza equivalente a RSA-3072 con una chiave di soli 256 bit:

# Generare una chiave Ed25519 con commento identificativo
ssh-keygen -t ed25519 -C "admin@server-produzione-$(date +%Y%m)"

# Output:
# Generating public/private ed25519 key pair.
# Enter file in which to save the key (/home/user/.ssh/id_ed25519):
# Enter passphrase (empty for no passphrase):

# IMPORTANTE: usare SEMPRE una passphrase robusta
# La chiave privata senza passphrase è come una password in chiaro su disco

Se avete ancora chiavi RSA, assicuratevi che siano almeno a 4096 bit:

# Solo se Ed25519 non è supportato dal sistema remoto
ssh-keygen -t rsa -b 4096 -C "admin@legacy-server"

Distribuzione Sicura delle Chiavi

# Copiare la chiave pubblica sul server remoto
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server

# Verificare i permessi sul server (cruciale per la sicurezza)
# Il server SSH rifiuta chiavi con permessi troppo permissivi
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Autenticazione FIDO2 con Chiavi Hardware: Il Livello Superiore

Le chiavi SSH tradizionali, per quanto protette da passphrase, restano file su disco. Un malware sofisticato o un attaccante con accesso al vostro filesystem può copiarle senza troppi problemi. Le chiavi hardware FIDO2 (come YubiKey, SoloKey o Nitrokey) risolvono questo problema alla radice: la chiave privata non lascia mai il dispositivo fisico.

OpenSSH supporta FIDO2 dalla versione 8.2. Con il tipo di chiave ed25519-sk (dove -sk sta per "security key"), la firma crittografica avviene interamente nell'hardware. Per ogni operazione SSH è richiesta la presenza fisica dell'utente — toccare il dispositivo — e, opzionalmente, un PIN FIDO2.

Vi dirò: dopo aver iniziato a usare una YubiKey per SSH, il pensiero di tornare alle chiavi su disco mi fa venire l'ansia.

Configurazione Passo per Passo

1. Impostare il PIN FIDO2 (se non l'avete ancora fatto):

# Con YubiKey Manager (GUI) oppure tramite CLI:
ykman fido access change-pin

# Il PIN protegge contro l'uso non autorizzato in caso di furto
# del dispositivo fisico

2. Generare la chiave SSH basata su hardware:

# Chiave ed25519-sk (raccomandata, richiede YubiKey firmware 5.2.3+)
ssh-keygen -t ed25519-sk -C "yubikey-admin-2026"

# Per YubiKey con firmware precedente, usare ecdsa-sk
ssh-keygen -t ecdsa-sk -C "yubikey-admin-2026"

# Opzione "resident": la chiave viene memorizzata sulla YubiKey stessa
# Permette di usarla su qualsiasi computer senza copiare file
ssh-keygen -t ed25519-sk -O resident -O verify-required -C "yubikey-portable"

3. Chiavi Resident vs Non-Resident:

Non-Resident (default): un "handle" della chiave viene salvato su disco (~/.ssh/id_ed25519_sk). La chiave privata resta sulla YubiKey, ma serve il file handle per usarla — funziona solo sul computer dove è stata generata
Resident (-O resident): la chiave è interamente sulla YubiKey. Potete usarla su qualsiasi computer estraendola con ssh-keygen -K. Ideale per chi lavora su più postazioni (e sappiamo tutti com'è fare il sysadmin nomade)

4. Recuperare le chiavi resident su un nuovo computer:

# Inserire la YubiKey e scaricare le chiavi residenti
ssh-keygen -K

# Verrà chiesto il PIN FIDO2
# Le chiavi verranno salvate nella directory corrente
# Spostarle in ~/.ssh/ e impostare i permessi corretti
mv id_ed25519_sk* ~/.ssh/
chmod 600 ~/.ssh/id_ed25519_sk

5. Configurare il server per accettare chiavi FIDO2:

# In /etc/ssh/sshd_config
PubkeyAuthentication yes
PubkeyAcceptedAlgorithms [email protected],ssh-ed25519,rsa-sha2-512

# Aggiungere la chiave pubblica al server come di consueto
# La chiave pubblica .pub generata va in authorized_keys

Con questa configurazione, ogni connessione SSH richiederà di toccare fisicamente la YubiKey e inserire il PIN. Anche se un attaccante compromettesse completamente la vostra workstation, non potrebbe usare le chiavi SSH senza il dispositivo fisico. È un livello di sicurezza fondamentalmente superiore.

Consiglio pratico: configurate sempre due chiavi FIDO2 — una primaria e una di backup — e registrate entrambe le chiavi pubbliche sui server. In caso di smarrimento o guasto, avrete sempre un modo per accedere. Fidatevi, non volete scoprire l'importanza di questo consiglio nel momento sbagliato.

Certificati SSH: Gestione Centralizzata delle Identità

In ambienti con decine o centinaia di server, gestire file authorized_keys su ogni macchina diventa un incubo operativo. Chi ci è passato lo sa fin troppo bene. I certificati SSH risolvono questo problema introducendo un modello basato su Certificate Authority (CA) — simile a TLS, ma per SSH.

Il concetto è semplice: una CA firma le chiavi pubbliche degli utenti generando certificati con scadenza temporale. I server si fidano della CA, non delle singole chiavi. Quando un utente lascia l'organizzazione, non dovete correre a rimuovere la sua chiave da ogni server — il certificato scade automaticamente. Elegante, no?

Implementazione Pratica

1. Creare due CA separate (una per utenti, una per host):

# CA per utenti
ssh-keygen -t ed25519 -f /etc/ssh/ca/user_ca -C "User CA 2026"

# CA per host (separata! I processi che aggiungono host
# non devono poter aggiungere utenti)
ssh-keygen -t ed25519 -f /etc/ssh/ca/host_ca -C "Host CA 2026"

# Proteggere le chiavi CA con permessi restrittivi
chmod 600 /etc/ssh/ca/user_ca /etc/ssh/ca/host_ca
chmod 644 /etc/ssh/ca/user_ca.pub /etc/ssh/ca/host_ca.pub

2. Firmare la chiave pubblica di un utente:

# Firma con scadenza a 8 ore e principal specifico
ssh-keygen -s /etc/ssh/ca/user_ca     -I "[email protected]"     -n mario     -V +8h     mario_id_ed25519.pub

# -s: chiave privata della CA
# -I: identificativo (appare nei log)
# -n: principal (deve corrispondere all'utente sul server)
# -V: validità (+8h = 8 ore, +52w = 52 settimane)

# Risultato: file mario_id_ed25519-cert.pub

3. Firmare la chiave host (così eliminate quei messaggi "trust on first use" che tutti accettano senza leggere):

# Firmare la chiave host del server
ssh-keygen -s /etc/ssh/ca/host_ca     -I "server-produzione.azienda.it"     -h     -n server-produzione.azienda.it     -V +52w     /etc/ssh/ssh_host_ed25519_key.pub

4. Configurare il server per accettare certificati utente:

# In /etc/ssh/sshd_config
TrustedUserCAKeys /etc/ssh/ca/user_ca.pub

# Opzionale: specificare i principal consentiti
AuthorizedPrincipalsFile /etc/ssh/auth_principals/%u

5. Configurare il client per fidarsi della CA host:

# In ~/.ssh/known_hosts o /etc/ssh/ssh_known_hosts
@cert-authority *.azienda.it ssh-ed25519 AAAA... [contenuto di host_ca.pub]

6. Verificare un certificato:

# Ispezionare i dettagli di un certificato
ssh-keygen -L -f mario_id_ed25519-cert.pub

# Output mostra: tipo, CA, Key ID, validità, principal, estensioni

Per ambienti enterprise, considerate l'uso di HashiCorp Vault per automatizzare la firma dei certificati. Vault può funzionare come CA SSH, firmando automaticamente le chiavi degli utenti autenticati tramite LDAP, OIDC o altri backend. Un bel risparmio di tempo quando avete decine di sviluppatori che ruotano di continuo.

Configurazione Hardened Completa di sshd_config

Ok, arriviamo al piatto forte. Ecco una configurazione sshd_config completa e commentata per un server di produzione nel 2026. Ogni direttiva è spiegata con il ragionamento alla base:

# /etc/ssh/sshd_config — Hardened Configuration 2026
# Testato con OpenSSH 10.x

# ============================================
# PROTOCOLLO E RETE
# ============================================

# Porta non standard: riduce il rumore dei bot automatizzati
# Non è sicurezza di per sé, ma alleggerisce i log
Port 2222

# Solo IPv4, a meno che non serviate IPv6
AddressFamily inet

# Bind solo sull'interfaccia necessaria (non su tutte)
# ListenAddress 10.0.1.50

# ============================================
# CRITTOGRAFIA
# ============================================

# Algoritmi di key exchange: post-quantum first
KexAlgorithms mlkem768x25519-sha256,[email protected],curve25519-sha256

# Cifratura: solo algoritmi moderni AEAD
Ciphers [email protected],[email protected],[email protected]

# MAC: solo Encrypt-then-MAC
MACs [email protected],[email protected]

# Chiavi host: solo Ed25519 (rimuovere ECDSA e RSA se possibile)
HostKey /etc/ssh/ssh_host_ed25519_key
HostKeyAlgorithms ssh-ed25519

# ============================================
# AUTENTICAZIONE
# ============================================

# Disabilitare COMPLETAMENTE le password
PasswordAuthentication no
KbdInteractiveAuthentication no
ChallengeResponseAuthentication no

# Abilitare solo autenticazione a chiave pubblica
PubkeyAuthentication yes
PubkeyAcceptedAlgorithms [email protected],ssh-ed25519,rsa-sha2-512

# Disabilitare login root diretto
PermitRootLogin no

# Limitare gli utenti autorizzati
AllowUsers admin deploy
# Oppure per gruppo: AllowGroups ssh-users

# Massimo 3 tentativi di autenticazione per connessione
MaxAuthTries 3

# Tempo massimo per completare il login: 30 secondi
LoginGraceTime 30

# Numero massimo di sessioni per connessione
MaxSessions 3

# Connessioni concorrenti non autenticate
MaxStartups 3:50:10

# ============================================
# RESTRIZIONI DI SESSIONE
# ============================================

# Disabilitare tutto ciò che non serve
X11Forwarding no
AllowTcpForwarding no
AllowAgentForwarding no
PermitTunnel no
GatewayPorts no

# Disabilitare motd e banner (meno info = meno ricognizione)
PrintMotd no

# Timeout di inattività: disconnettere dopo 10 minuti
ClientAliveInterval 300
ClientAliveCountMax 2

# Logging dettagliato per auditing
LogLevel VERBOSE

# Chroot per utenti SFTP (esempio)
# Match User sftpuser
#     ChrootDirectory /data/sftp/%u
#     ForceCommand internal-sftp
#     AllowTcpForwarding no

Dopo ogni modifica, verificate sempre la configurazione prima di riavviare il servizio. Questo è un passaggio che non dovete mai saltare:

# Verificare la sintassi della configurazione
sudo sshd -t

# Se non ci sono errori, riavviare il servizio
sudo systemctl restart sshd

# ATTENZIONE: mantenere SEMPRE una sessione SSH aperta
# mentre testate le modifiche. Se la nuova configurazione
# vi blocca fuori, la sessione esistente resta attiva

Quel consiglio sulla sessione aperta non è retorica — l'ho imparato sulla mia pelle. Bloccarsi fuori da un server in produzione alle 2 di notte non è un'esperienza che si dimentica facilmente.

Verifica con ssh-audit

Lo strumento ssh-audit è essenziale per validare la configurazione. Pensatelo come un "secondo paio di occhi" automatizzato:

# Installazione
pip install ssh-audit

# Audit del server
ssh-audit server.example.com

# L'output mostra:
# - Algoritmi supportati con valutazione di sicurezza
# - Vulnerabilità note
# - Conformità con le best practice
# - Raccomandazioni specifiche per il hardening

Difesa Proattiva: Fail2Ban vs CrowdSec

Anche con autenticazione a chiave e crittografia post-quantum, i tentativi di connessione malevoli continuano ad arrivare. Consumano risorse, riempiono i log e, onestamente, danno fastidio. Strumenti di protezione attiva sono un livello di difesa che non dovreste ignorare.

Fail2Ban: Il Veterano Affidabile

Fail2Ban è in circolazione dal 2004 — più vecchio di molti sysadmin che lo usano — e resta lo strumento più diffuso per la protezione SSH. Monitora i log, rileva pattern sospetti (tipo 5 tentativi falliti in 60 secondi) e blocca gli IP tramite regole firewall.

# Installazione su Debian/Ubuntu
sudo apt install fail2ban

# Configurazione per SSH: /etc/fail2ban/jail.local
[sshd]
enabled = true
port = 2222
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
findtime = 600
bantime = 3600
banaction = nftables

# Comandi utili
sudo fail2ban-client status sshd          # Stato del jail SSH
sudo fail2ban-client set sshd unbanip IP  # Sbloccare un IP

Vantaggi: leggero, semplice, affidabile, ottimo per server singoli con risorse limitate.

Limiti: è reattivo (agisce solo dopo i tentativi falliti), offre protezione solo locale ed è vulnerabile ad attacchi distribuiti da migliaia di IP diversi.

CrowdSec: L'Intelligenza Collettiva

CrowdSec, nato nel 2020, introduce un approccio radicalmente diverso: la threat intelligence collaborativa. Quando un utente CrowdSec rileva un attaccante, l'IP viene condiviso con l'intera community, permettendo a tutti gli altri di bloccarlo proattivamente — prima che l'attacco arrivi al loro server. È un po' come un sistema immunitario distribuito.

La rete di CrowdSec elabora oltre un milione di IP unici al giorno, fornendo protezione in tempo reale contro minacce emergenti.

# Installazione su Debian/Ubuntu
curl -s https://install.crowdsec.net | sudo sh
sudo apt install crowdsec crowdsec-firewall-bouncer-nftables

# Verificare le collection installate (SSH è incluso di default)
sudo cscli collections list

# Verificare le decisioni attive (IP bloccati)
sudo cscli decisions list

# Statistiche sugli attacchi rilevati
sudo cscli metrics

# Aggiungere un bouncer per nftables
sudo cscli bouncers add firewall-bouncer

Architettura CrowdSec:

Agent: analizza i log e rileva comportamenti sospetti tramite "scenari" (simili ai filtri di Fail2Ban, ma più sofisticati)
LAPI (Local API): gestisce le decisioni di blocco e comunica con la Central API
Bouncer: applica le decisioni — blocco firewall, CAPTCHA, rate limiting
Central API: la rete collaborativa globale che condivide la threat intelligence

Vantaggi: proattivo, intelligenza collettiva, rileva attacchi distribuiti, architettura moderna e scalabile.

Limiti: dipendenza dalla Central API (gestita da un'azienda privata), consumo risorse leggermente superiore a Fail2Ban.

Strategia Combinata: Il Meglio di Entrambi

Nella pratica, la configurazione ottimale prevede l'uso combinato dei due strumenti:

CrowdSec: protezione globale e proattiva, blocco preventivo di IP noti malevoli
Fail2Ban: protezione locale immediata come rete di sicurezza aggiuntiva

In questa configurazione, CrowdSec blocca la maggior parte degli attaccanti prima ancora che tentino la connessione, mentre Fail2Ban agisce come secondo livello per i rari attaccanti che sfuggono alla rete collaborativa. Cintura e bretelle, insomma.

Architettura Bastion Host: Il Gateway Blindato

In ambienti di produzione, nessun server critico dovrebbe avere la porta SSH esposta direttamente a Internet. L'architettura bastion host (o jump server) crea un unico punto di ingresso controllato alla vostra rete. È un principio fondamentale, eppure vedo ancora troppi ambienti dove ogni server ha la porta 22 aperta al mondo.

Principi dell'Architettura

# Architettura di rete con bastion host
#
# Internet
#     |
#     v
# [Firewall] --- Solo porta 2222 aperta verso il bastion
#     |
#     v
# [Bastion Host] --- Server minimale, hardened al massimo
#     |
#     v
# [Rete Interna]
#     |--- Server App 1 (SSH porta 22, solo dalla rete interna)
#     |--- Server App 2 (SSH porta 22, solo dalla rete interna)
#     |--- Server DB    (SSH porta 22, solo dalla rete interna)
#     |--- Server Logs  (SSH porta 22, solo dalla rete interna)

Configurazione del Jump tramite SSH Config

Con la direttiva ProxyJump (disponibile da OpenSSH 7.3+), la connessione attraverso il bastion è completamente trasparente:

# ~/.ssh/config

# Definizione del bastion host
Host bastion
    HostName bastion.azienda.it
    Port 2222
    User admin
    IdentityFile ~/.ssh/id_ed25519_sk
    # Timeout aggressivo
    ConnectTimeout 10
    ServerAliveInterval 60

# Server interni: passano automaticamente attraverso il bastion
Host server-app-1
    HostName 10.0.1.10
    User deploy
    ProxyJump bastion
    IdentityFile ~/.ssh/id_ed25519

Host server-db
    HostName 10.0.1.20
    User dbadmin
    ProxyJump bastion
    IdentityFile ~/.ssh/id_ed25519

# Wildcard per tutti i server interni
Host 10.0.1.*
    ProxyJump bastion
    User admin

Con questa configurazione, il comando ssh server-app-1 attraversa automaticamente il bastion senza passaggi intermedi. Nessun doppio login, nessuna complicazione.

Hardening del Bastion Host

Il bastion deve essere la macchina più hardened della vostra intera infrastruttura. Nessuna eccezione:

Sistema operativo minimale: nessun servizio oltre SSH. Niente web server, niente database, niente tool di sviluppo — niente di niente
Autenticazione FIDO2 obbligatoria: l'accesso al bastion richiede una chiave hardware
Logging completo: ogni sessione registrata e inviata a un SIEM esterno
Aggiornamenti automatici: patch di sicurezza applicate automaticamente
AllowTcpForwarding e AllowAgentForwarding configurati per utente tramite blocchi Match
Nessun accesso outbound: il bastion non può iniziare connessioni verso Internet

Monitoraggio, Audit e Cadenza di Sicurezza

L'hardening SSH non è un'operazione una tantum. È un processo continuo che richiede monitoraggio costante e revisioni periodiche. So che non è la parte più entusiasmante, ma è quella che fa la differenza tra un server sicuro e uno che lo era.

Centralizzazione dei Log

I log SSH locali possono essere manipolati da un attaccante con privilegi sufficienti. Inoltrate sempre i log a un sistema esterno:

# Configurare rsyslog per inoltrare i log SSH a un server centrale
# In /etc/rsyslog.d/50-ssh-forward.conf
:programname, isequal, "sshd" @@logserver.azienda.it:514

# In sshd_config, assicurarsi che il logging sia verboso
LogLevel VERBOSE

Con LogLevel VERBOSE, il server SSH registra il fingerprint della chiave usata per ogni accesso. Questo è fondamentale per correlare gli accessi alle chiavi specifiche e identificare eventuali chiavi compromesse.

Audit delle Chiavi Autorizzate

# Script di audit: trova tutte le chiavi autorizzate sul sistema
#!/bin/bash
echo "=== Audit chiavi SSH autorizzate ==="
echo "Data: $(date -u +%Y-%m-%dT%H:%M:%SZ)"
echo ""

for user_home in /home/*; do
    user=$(basename "$user_home")
    auth_keys="$user_home/.ssh/authorized_keys"
    if [ -f "$auth_keys" ]; then
        count=$(wc -l < "$auth_keys")
        echo "Utente: $user — $count chiavi autorizzate"
        while IFS= read -r line; do
            # Estrarre il tipo e il commento della chiave
            key_type=$(echo "$line" | awk '{print $1}')
            key_comment=$(echo "$line" | awk '{print $NF}')
            echo "  Tipo: $key_type | Commento: $key_comment"
        done < "$auth_keys"
        echo ""
    fi
done

Cadenza di Sicurezza Raccomandata

Adottate una cadenza strutturata per la manutenzione della sicurezza SSH. Ecco quella che ho trovato funzionare meglio nella pratica:

Settimanale: revisione delle patch disponibili e applicazione degli aggiornamenti di sicurezza. Un'occhiata ai log per individuare picchi anomali di tentativi di autenticazione
Mensile: audit delle porte e dei servizi esposti con ss -tlnp e Nmap. Esecuzione di ssh-audit su tutti i server
Trimestrale: revisione degli accessi — via gli account inutilizzati e le chiavi SSH orfane. Rotazione delle chiavi CA (se usate). Test di ripristino dai backup. Verifica che le configurazioni sshd_config siano allineate alla baseline di sicurezza
Annuale: valutazione completa della postura di sicurezza con strumenti come Lynis. Revisione degli algoritmi crittografici alla luce delle nuove raccomandazioni NIST e ENISA

Automazione con Lynis

# Installare Lynis
sudo apt install lynis

# Eseguire un audit completo del sistema
sudo lynis audit system

# Per un audit focalizzato su SSH:
sudo lynis audit system --tests-from-group "ssh"

# L'output include un punteggio di hardening e raccomandazioni
# specifiche con riferimenti ai CIS Benchmarks

Checklist Riepilogativa per il 2026

Per chiudere, ecco un riepilogo delle priorità per l'hardening SSH, ordinate per criticità. Stampatela, attaccatela al monitor, fatene quello che volete — ma seguitela:

Critico: disabilitare l'autenticazione tramite password. Usare chiavi Ed25519. Disabilitare il login root diretto. Aggiornare a OpenSSH 10.x
Alto: configurare la crittografia post-quantum (mlkem768x25519, sntrup761x25519). Implementare FIDO2 per gli amministratori. Installare CrowdSec e/o Fail2Ban. Restringere gli utenti con AllowUsers/AllowGroups. Centralizzare i log
Medio: cambiare la porta SSH di default. Implementare i certificati SSH per ambienti con molti server. Utilizzare un bastion host. Eseguire audit regolari con ssh-audit e Lynis
Consigliato: adottare la cadenza di sicurezza settimanale/mensile/trimestrale. Automatizzare gli aggiornamenti di sicurezza. Integrare il monitoraggio SSH in un SIEM

Conclusione

L'hardening SSH nel 2026 non è più solo questione di disabilitare le password e cambiare la porta. Con la crittografia post-quantum in OpenSSH 10.0, l'autenticazione FIDO2 con chiavi hardware e la difesa proattiva tramite intelligenza collettiva con CrowdSec, abbiamo a disposizione strumenti che rendono le connessioni SSH significativamente più sicure rispetto a anche solo un paio d'anni fa.

La backdoor XZ Utils ci ha ricordato che le minacce possono arrivare da dove meno ce le aspettiamo, e le 5.530 CVE del kernel Linux nel 2025 dimostrano che la superficie di attacco continua a crescere. Ma con una configurazione SSH solida — crittografia moderna, autenticazione hardware, certificati a scadenza, architettura bastion e monitoraggio continuo — potete costruire una difesa in profondità che resiste anche agli attaccanti più determinati.

La sicurezza non è una destinazione, è un viaggio. Iniziate dalle misure critiche, implementate progressivamente quelle ad alta priorità e mantenete la cadenza di revisione. I vostri server ve ne saranno grati — e gli attaccanti molto meno.