Hardening SSH su VPS Linux: guida sshd

SSH e la porta d'ingresso del tuo server. Bot automatizzati iniziano a martellare la porta 22 pochi minuti dopo l'attivazione di un VPS. Questa guida copre ogni modifica a sshd_config necessaria per mettere in sicurezza SSH su Debian 12 (OpenSSH 9.2) e Ubuntu 24.04 (OpenSSH 9.6), con un passaggio di verifica dopo ogni modifica per confermare che funziona.

Prerequisiti

Servono:

Un VPS con Debian 12 o Ubuntu 24.04 (nuovo o esistente)
Un utente non-root con accesso sudo
Un secondo terminale o sessione SSH aperta sul server (serve per testare le modifiche senza rischiare di restare chiusi fuori)

Questa guida fa parte della serie Linux VPS Security: Threats, Layers, and Hardening Guide. Dopo aver messo in sicurezza SSH, configura la protezione automatica da brute-force con .

Come generare una chiave SSH sicura per il VPS

Genera una chiave Ed25519 sulla tua macchina locale (il portatile o la workstation, non il server). Ed25519 produce una chiave a 256 bit che offre 128 bit di sicurezza, equivalente a RSA-3072, pur essendo piu veloce da generare e verificare. Le firme sono deterministiche e non dipendono da un generatore di numeri casuali al momento della firma. Questo elimina un'intera classe di attacchi implementativi che colpiscono RSA.

ssh-keygen -t ed25519 -C "yourname@yourmachine"

Vedrai un output simile a questo:

Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/yourname/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/yourname/.ssh/id_ed25519
Your public key has been saved in /home/yourname/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:xR5xGk3TOs4mEfW8sBv7g7LkE2PLxYae2TqfGxpfM3Q yourname@yourmachine

Imposta una passphrase. Se qualcuno ruba il file della chiave privata, la passphrase e l'unica barriera tra lui e i tuoi server.

Ed25519 vs RSA: quale chiave usare?

	Ed25519	RSA-4096
Dimensione chiave	256 bit	4096 bit
Livello di sicurezza	~128 bit	~140 bit
Generazione chiave	Istantanea	1-5 secondi
Verifica firma	Piu veloce	Piu lenta
Dimensione chiave privata	464 byte	~3.3 KB
Dipendenza da RNG alla firma	No (deterministica)	Si
Compatibilita	OpenSSH 6.5+ (2014)	Universale

Usa Ed25519 a meno che tu non debba connetterti a sistemi con OpenSSH precedente alla versione 6.5, cosa rara nel 2026.

Copia la chiave pubblica sul server

Dalla macchina locale:

ssh-copy-id -i ~/.ssh/id_ed25519.pub youruser@your-server-ip

Se ssh-copy-id non e disponibile (alcune configurazioni macOS), copia manualmente:

cat ~/.ssh/id_ed25519.pub | ssh youruser@your-server-ip "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Verifica: accedi da un nuovo terminale usando l'autenticazione con chiave:

ssh -i ~/.ssh/id_ed25519 youruser@your-server-ip

Se ottieni una shell senza inserire la password del server (solo la passphrase della chiave), l'autenticazione con chiave funziona.

La direttiva Include

Prima di modificare sshd_config, tieni presente che sia Debian 12 che Ubuntu 24.04 includono Include /etc/ssh/sshd_config.d/*.conf in cima a /etc/ssh/sshd_config. OpenSSH usa il primo valore trovato per la maggior parte delle direttive. Qualsiasi file .conf in sshd_config.d/ ha priorita sulle impostazioni del file principale.

Controlla cosa e gia configurato:

ls -la /etc/ssh/sshd_config.d/

Su Ubuntu 24.04 troverai tipicamente 50-cloud-init.conf se cloud-init e attivo. Leggi i file esistenti prima di apportare modifiche:

cat /etc/ssh/sshd_config.d/*.conf 2>/dev/null

Il nostro hardening va in un singolo file che viene caricato per primo:

sudo touch /etc/ssh/sshd_config.d/00-hardening.conf
sudo chmod 600 /etc/ssh/sshd_config.d/00-hardening.conf

Il prefisso 00- assicura che il file venga letto prima degli altri frammenti di configurazione. Il chmod 600 limita l'accesso in lettura al solo root, dato che questo file controlla chi puo accedere.

Tutte le modifiche a sshd_config in questa guida vanno in /etc/ssh/sshd_config.d/00-hardening.conf salvo diversa indicazione.

Come disabilitare l'autenticazione SSH con password

Disabilitare l'autenticazione con password forza il login solo con chiave. Gli attacchi brute-force diventano inutili perche non c'e nessuna password da indovinare.

Apri il file di hardening:

sudo nano /etc/ssh/sshd_config.d/00-hardening.conf

Aggiungi:

PasswordAuthentication no
KbdInteractiveAuthentication no

KbdInteractiveAuthentication sostituisce la direttiva deprecata ChallengeResponseAuthentication in OpenSSH 9.x. Disabilita entrambe per chiudere tutti i percorsi di login basati su password.

Prima di riavviare sshd, valida sempre la configurazione e tieni aperta la sessione corrente.

sudo sshd -t

Se non c'e output, la configurazione e valida. Eventuali errori vengono stampati a terminale.

Riavvia sshd:

sudo systemctl restart sshd

Verifica da un secondo terminale (non chiudere la sessione corrente):

ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no youruser@your-server-ip

Dovresti vedere:

youruser@your-server-ip: Permission denied (publickey).

Questo conferma che l'autenticazione con password e disattivata. Nota che dice (publickey) come unico metodo consentito. Esattamente quello che vogliamo.

Ora conferma che il login con chiave funziona ancora dallo stesso secondo terminale:

ssh youruser@your-server-ip

Se entrambi i test passano, l'autenticazione con password e disabilitata e il login con chiave funziona. Se il login con chiave fallisce, torna alla prima sessione ancora aperta e correggi la configurazione prima di restare chiuso fuori.

Il login diretto come root via SSH deve essere disattivato. Anche con autenticazione solo con chiave, una chiave compromessa per root da accesso completo al sistema senza traccia di chi si e collegato. Usa un utente normale con sudo.

Aggiungi a /etc/ssh/sshd_config.d/00-hardening.conf:

PermitRootLogin no

Valida e riavvia:

sudo sshd -t && sudo systemctl restart sshd

Verifica da un secondo terminale:

ssh root@your-server-ip

Output atteso:

root@your-server-ip: Permission denied (publickey).

Verifica che l'impostazione sia attiva con sshd -T (la T maiuscola mostra la configurazione in esecuzione):

sudo sshd -T | grep -i permitrootlogin

permitrootlogin no

Come limitare l'accesso SSH a utenti e gruppi specifici

AllowUsers e AllowGroups limitano il login SSH a una lista esplicita. Chiunque non sia nella lista viene rifiutato, anche se ha chiavi valide. E una rete di sicurezza contro il deploy accidentale di chiavi o nuovi utenti creati da pacchetti.

Aggiungi a /etc/ssh/sshd_config.d/00-hardening.conf:

AllowUsers youruser

Sostituisci youruser con il tuo nome utente reale. Per consentire piu utenti:

AllowUsers youruser deployer

In alternativa, usa l'accesso basato su gruppi (meglio per i team):

sudo groupadd sshusers
sudo usermod -aG sshusers youruser

Poi nella configurazione:

AllowGroups sshusers

Ordine di elaborazione

OpenSSH valuta l'accesso in questo ordine: DenyUsers, AllowUsers, DenyGroups, AllowGroups. Un deny in qualsiasi fase blocca l'utente. Se usi AllowUsers, solo gli utenti elencati possono accedere. Se usi AllowGroups, solo i membri dei gruppi elencati possono accedere. Puoi combinarli, ma AllowUsers viene valutato per primo.

Valida e riavvia:

sudo sshd -t && sudo systemctl restart sshd

Verifica da un secondo terminale:

ssh youruser@your-server-ip

Conferma che il tuo utente riesce ancora ad accedere. Poi verifica che un utente non in lista verrebbe rifiutato:

sudo sshd -T | grep -i allowusers

allowusers youruser

Quali limiti di sessione SSH impostare?

Queste direttive limitano i tentativi di autenticazione, i timeout di connessione e le connessioni non autenticate. Rallentano gli attacchi brute-force e ripuliscono le sessioni inattive.

Aggiungi a /etc/ssh/sshd_config.d/00-hardening.conf:

MaxAuthTries 3
LoginGraceTime 20
MaxStartups 10:30:60
MaxSessions 3
ClientAliveInterval 300
ClientAliveCountMax 2

Ecco cosa fa ogni impostazione:

Direttiva	Valore	Effetto
MaxAuthTries	3	Disconnette dopo 3 tentativi di autenticazione falliti per connessione
LoginGraceTime	20	Concede 20 secondi per autenticarsi prima della disconnessione
MaxStartups	10:30:60	Dopo 10 connessioni non autenticate, scarta casualmente il 30% delle nuove. A 60, scarta tutte le nuove connessioni.
MaxSessions	3	Massimo 3 sessioni multiplexate per connessione
ClientAliveInterval	300	Invia un pacchetto keepalive ogni 300 secondi (5 minuti)
ClientAliveCountMax	2	Disconnette dopo 2 risposte keepalive mancate

Calcolo ClientAliveInterval: il timeout effettivo per inattivita e ClientAliveInterval x ClientAliveCountMax. Con questi valori: 300 x 2 = 600 secondi = 10 minuti. Una sessione inattiva viene disconnessa dopo 10 minuti senza risposta.

Valida e riavvia:

sudo sshd -t && sudo systemctl restart sshd

Verifica:

sudo sshd -T | grep -E "maxauthtries|logingracetime|maxstartups|maxsessions|clientaliveinterval|clientalivecountmax"

maxauthtries 3
logingracetime 20
maxstartups 10:30:60
maxsessions 3
clientaliveinterval 300
clientalivecountmax 2

Disabilitare le funzionalita di forwarding non necessarie

Le funzionalita di forwarding ampliano la superficie di attacco di SSH. Disabilita tutto quello che non usi attivamente.

Aggiungi a /etc/ssh/sshd_config.d/00-hardening.conf:

AllowAgentForwarding no
AllowTcpForwarding no
X11Forwarding no
PermitTunnel no

Valida e riavvia:

sudo sshd -t && sudo systemctl restart sshd

Verifica:

sudo sshd -T | grep -E "allowagentforwarding|allowtcpforwarding|x11forwarding|permittunnel"

allowagentforwarding no
allowtcpforwarding no
x11forwarding no
permittunnel no

Perche disabilitare l'agent forwarding SSH?

L'agent forwarding permette a un server remoto di usare le tue chiavi SSH locali per autenticarsi su altri server. Sembra comodo per saltare tra macchine. Il problema: chiunque abbia root su quel server remoto puo dirottare il socket del tuo agent e usare le tue chiavi.

Lo scenario di attacco:

Abiliti l'agent forwarding e ti colleghi via SSH al Server A.
OpenSSH crea un socket in /tmp/ssh-XXXX/agent.YYYY sul Server A.
Un attaccante con root sul Server A legge la variabile d'ambiente SSH_AUTH_SOCK dalla tua sessione.
L'attaccante si connette a quel socket: SSH_AUTH_SOCK=/tmp/ssh-XXXX/agent.YYYY ssh user@server-b.
Il Server B vede un'autenticazione valida con la tua chiave. L'attaccante e dentro.

L'attaccante non ha mai toccato la tua chiave privata. Gli bastava avere root sul server intermedio mentre la tua sessione era attiva.

Usa ProxyJump (sezione successiva). Fornisce lo stesso accesso multi-hop senza esporre il socket dell'agent a nessun server intermedio.

Come configurare SSH ProxyJump per l'accesso tramite bastion host

ProxyJump instrada la connessione SSH attraverso un jump host (bastion) senza agent forwarding. Le tue chiavi non lasciano mai la macchina locale. La connessione e cifrata end-to-end: il bastion vede solo traffico cifrato in transito.

Uso da riga di comando

ssh -J jumpuser@bastion.example.com targetuser@10.0.1.50

Il flag -J dice a SSH di connettersi prima al bastion, poi creare un tunnel verso il target. Puoi concatenare piu salti con le virgole:

ssh -J jump1@bastion1,jump2@bastion2 targetuser@10.0.1.50

Configurazione nel file SSH config

Per l'uso regolare, aggiungi le voci a ~/.ssh/config sulla tua macchina locale:

Host bastion
    HostName bastion.example.com
    User jumpuser
    IdentityFile ~/.ssh/id_ed25519

Host internal-app
    HostName 10.0.1.50
    User appuser
    ProxyJump bastion
    IdentityFile ~/.ssh/id_ed25519

Host internal-db
    HostName 10.0.2.100
    User dbadmin
    ProxyJump bastion
    IdentityFile ~/.ssh/id_ed25519

Ora connettiti ai server interni direttamente:

ssh internal-app

SSH gestisce il passaggio dal bastion automaticamente.

Hardening del bastion server

Sul bastion host, limita cosa possono fare gli utenti jump. Aggiungi al sshd_config del bastion:

Match User jumpuser
    PermitTTY no
    X11Forwarding no
    PermitTunnel no
    ForceCommand /usr/sbin/nologin
    AllowTcpForwarding yes

Questo consente il TCP forwarding (necessario per ProxyJump) ma impedisce all'utente jump di ottenere una shell, eseguire comandi o usare X11. Se il bastion viene compromesso, l'attaccante ottiene un account solo per il forwarding senza accesso alla shell.

Quali cifrature e algoritmi di scambio chiavi SSH sono sicuri?

Le liste di cifratura predefinite di OpenSSH includono algoritmi mantenuti per retrocompatibilita. Rimuovere quelli deboli riduce la superficie di attacco. Queste raccomandazioni sono per OpenSSH 9.2+ (Debian 12) e 9.6+ (Ubuntu 24.04).

Prima rigenera le chiavi host usando solo Ed25519 e rimuovi le chiavi DSA o ECDSA:

sudo rm -f /etc/ssh/ssh_host_*key*
sudo ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key -N ""
sudo ssh-keygen -t rsa -b 4096 -f /etc/ssh/ssh_host_rsa_key -N ""

Manteniamo una chiave host RSA per i client che non supportano Ed25519 (raro, ma evita blocchi).

Poi rimuovi i moduli Diffie-Hellman deboli (gruppi inferiori a 3072 bit):

sudo awk '$5 >= 3071' /etc/ssh/moduli > /tmp/moduli.safe
sudo mv /tmp/moduli.safe /etc/ssh/moduli
sudo chown root:root /etc/ssh/moduli
sudo chmod 644 /etc/ssh/moduli

Aggiungi a /etc/ssh/sshd_config.d/00-hardening.conf:

HostKeyAlgorithms ssh-ed25519-cert-v01@openssh.com,ssh-ed25519,rsa-sha2-512,rsa-sha2-256
KexAlgorithms sntrup761x25519-sha512@openssh.com,curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com

Categoria	Algoritmi	Note
Scambio chiavi	sntrup761x25519, curve25519, DH group16/18	sntrup761 e un ibrido post-quantistico. curve25519 e lo standard attuale.
Cifrature	ChaCha20-Poly1305, AES-256-GCM, AES-128-GCM, AES-CTR	ChaCha20 per primo: piu veloce via software senza AES-NI. GCM e cifratura autenticata.
MAC	HMAC-SHA2 ETM, UMAC-128 ETM	Solo ETM (Encrypt-then-MAC). Le modalita non-ETM sono piu deboli.
Chiavi host	Ed25519, RSA (SHA-2)	Niente DSA (compromesso). Niente ECDSA (dubbi sulle curve NIST).

Valida e riavvia:

sudo sshd -t && sudo systemctl restart sshd

Verifica da un secondo terminale che riesci ancora a connetterti. Se il tuo client SSH non supporta nessuno di questi algoritmi (client molto vecchio), otterrai un errore "no matching cipher". In quel caso, aggiorna il client o riaggiungi temporaneamente l'algoritmo necessario.

Nascondi le informazioni sulla versione SSH e mostra un avviso legale:

sudo nano /etc/ssh/banner.txt

Authorized access only. All activity is monitored and logged.

Mantienilo breve. Banner lunghi con informazioni di sistema aiutano gli attaccanti a identificare il tuo sistema operativo.

Aggiungi a /etc/ssh/sshd_config.d/00-hardening.conf:

Banner /etc/ssh/banner.txt
DebianBanner no

DebianBanner no rimuove la stringa di versione Debian/Ubuntu dal banner del protocollo SSH. Rivelare la versione aiuta gli attaccanti a puntare vulnerabilita note per la tua specifica build di OpenSSH.

Valida e riavvia:

sudo sshd -t && sudo systemctl restart sshd

Verifica dalla macchina locale:

ssh -v youruser@your-server-ip 2>&1 | grep "banner"

Riferimento completo sshd_config con hardening

Ecco il file completo /etc/ssh/sshd_config.d/00-hardening.conf con tutte le impostazioni di questa guida:

# Authentication
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
AuthenticationMethods publickey

# Access control
AllowUsers youruser

# Session limits
MaxAuthTries 3
LoginGraceTime 20
MaxStartups 10:30:60
MaxSessions 3
ClientAliveInterval 300
ClientAliveCountMax 2

# Forwarding restrictions
AllowAgentForwarding no
AllowTcpForwarding no
X11Forwarding no
PermitTunnel no

# Cryptography
HostKeyAlgorithms ssh-ed25519-cert-v01@openssh.com,ssh-ed25519,rsa-sha2-512,rsa-sha2-256
KexAlgorithms sntrup761x25519-sha512@openssh.com,curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com

# Banner
Banner /etc/ssh/banner.txt
DebianBanner no

# Logging
LogLevel VERBOSE

LogLevel VERBOSE registra dettagli aggiuntivi tra cui le impronte digitali delle chiavi usate per l'autenticazione. Utile per verificare chi ha effettuato l'accesso e con quale chiave.

Dopo aver scritto questo file, valida sempre prima di riavviare:

sudo sshd -t && sudo systemctl restart sshd

Controlla la configurazione effettiva completa:

sudo sshd -T

Questo mostra ogni impostazione attiva, incluse quelle predefinite. Filtra con grep per controllare valori specifici:

sudo sshd -T | grep -E "permitrootlogin|passwordauthentication|allowusers"

permitrootlogin no
passwordauthentication no
allowusers youruser

Come verificare l'hardening SSH con ssh-audit

ssh-audit analizza il server e valuta ogni algoritmo come buono, warning o fallito. Eseguilo dopo l'hardening per confermare che tutto passa.

Installa sulla tua macchina locale o su un server separato (non il target):

pip3 install ssh-audit

O con apt su Debian/Ubuntu:

sudo apt update && sudo apt install -y ssh-audit

Analizza il server:

ssh-audit your-server-ip

Con l'hardening di questa guida, non dovresti vedere voci [fail]. L'output inizia con la versione OpenSSH rilevata, poi elenca ogni categoria di algoritmi:

# general
(gen) banner: SSH-2.0-OpenSSH_9.6
(gen) software: OpenSSH 9.6
(gen) compression: enabled (zlib@openssh.com)

# key exchange algorithms
(kex) sntrup761x25519-sha512@openssh.com  -- [info] available since OpenSSH 8.5
(kex) curve25519-sha256                   -- [info] available since OpenSSH 7.4
...

# encryption algorithms (ciphers)
(enc) chacha20-poly1305@openssh.com       -- [info] available since OpenSSH 6.5
(enc) aes256-gcm@openssh.com              -- [info] available since OpenSSH 6.2
...

Se vedi voci [fail], controlla che 00-hardening.conf sia caricato (ricorda l'ordine di Include) e che nessun altro file in sshd_config.d/ stia sovrascrivendo le tue impostazioni.

ssh-audit include anche guide di hardening integrate:

ssh-audit --list-hardening-guides

Risoluzione problemi

Sono rimasto chiuso fuori

Se non riesci ad accedere via SSH dopo una modifica alla configurazione:

Usa la console web del tuo provider VPS (KVM/VNC) per accedere direttamente.
Correggi /etc/ssh/sshd_config.d/00-hardening.conf.
Esegui sshd -t per validare.
Riavvia: systemctl restart sshd.

Per questo diciamo: non chiudere mai la sessione funzionante prima di testare da un secondo terminale.

sshd non si avvia dopo una modifica alla configurazione

sudo sshd -t

Questo stampa la riga esatta e il file con l'errore. Problemi frequenti:

Errore di battitura nel nome di un algoritmo (niente spazi nelle liste separate da virgole)
Direttive duplicate in piu file (controlla sshd_config.d/ e il file principale sshd_config)
AllowUsers con un nome utente che non esiste (sshd si avvia, ma nessuno riesce ad accedere)

Connessione rifiutata dopo l'hardening delle cifrature

Il client SSH locale potrebbe non supportare le cifrature configurate. Controlla quali cifrature supporta il tuo client:

ssh -Q cipher

Confronta con la lista del server. Riaggiungi la cifratura necessaria al client, oppure aggiorna il client.

Controllare i log SSH

sudo journalctl -u sshd -f

Guarda i log in tempo reale mentre tenti una connessione da un altro terminale. Errori di autenticazione, errori di configurazione e disconnessioni compaiono tutti qui.

Verificare quale file di configurazione imposta una direttiva

sudo sshd -T | grep passwordauthentication

Se il valore non corrisponde a quello impostato, un altro file in sshd_config.d/ sta sovrascrivendo il tuo. I file vengono caricati in ordine alfabetico. Il nostro 00-hardening.conf viene caricato per primo, quindi ha la precedenza per la maggior parte delle direttive. Ma controlla se cloud-init o altri strumenti di gestione scrivono le proprie configurazioni.

Checklist di verifica

Esegui questi controlli dopo aver completato tutti i passaggi di hardening:

Autenticazione password disabilitata: ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no youruser@server restituisce "Permission denied"
Login root disabilitato: ssh root@server restituisce "Permission denied"
Autenticazione con chiave funzionante: ssh youruser@server fornisce una shell
AllowUsers attivo: sudo sshd -T | grep allowusers mostra il tuo utente
Limiti di sessione impostati: sudo sshd -T | grep maxauthtries mostra 3
Forwarding disabilitato: sudo sshd -T | grep allowagentforwarding mostra no
Solo cifrature forti: ssh-audit server-ip non mostra voci [fail]
Log funzionanti: sudo journalctl -u sshd -n 20 mostra le voci di autenticazione recenti

Dopo aver messo in sicurezza SSH, configura per bannare automaticamente gli IP che falliscono l'autenticazione. Per il controllo degli accessi SSH a livello di rete, vedi .

Copyright 2026 Virtua.Cloud. Tutti i diritti riservati. Questo contenuto e un'opera originale del team Virtua.Cloud. La riproduzione, ripubblicazione o redistribuzione senza autorizzazione scritta e vietata.