{"id":130,"date":"2026-06-14T20:31:19","date_gmt":"2026-06-14T20:31:19","guid":{"rendered":"https:\/\/shattered.io\/it\/2026\/06\/14\/chiavi-ssh-ed25519-hardening-server\/"},"modified":"2026-06-14T20:32:37","modified_gmt":"2026-06-14T20:32:37","slug":"chiavi-ssh-ed25519-hardening-server","status":"publish","type":"post","link":"https:\/\/shattered.io\/it\/2026\/06\/14\/chiavi-ssh-ed25519-hardening-server\/","title":{"rendered":"Chiavi SSH Ed25519: Hardening Server in 12 Step [2026]"},"content":{"rendered":"\n

Le password SSH sono il bersaglio numero uno dei bot che scansionano internet. Un server Ubuntu appena esposto sulla porta 22 riceve migliaia di tentativi di login al giorno, spesso entro pochi minuti dall’accensione. La difesa definitiva non \u00e8 una password pi\u00f9 lunga, ma l’eliminazione totale delle password a favore della crittografia a chiave pubblica. In questo tutorial configuri l’autenticazione SSH con chiavi Ed25519<\/strong>, generi la coppia con ssh-keygen<\/strong>, blindi sshd_config<\/code> e installi fail2ban, fino a ottenere un server che accetta solo connessioni firmate crittograficamente.<\/p>\n\n\n\n

Il percorso \u00e8 organizzato in 12 step concreti, con comandi pronti da incollare, esempi di output reali e una checklist finale. Lavoriamo su OpenSSH 10.3p1 (rilasciato il 2 aprile 2026) e Ubuntu Server, ma i comandi valgono identici su Debian, Rocky Linux e qualsiasi distribuzione moderna. Alla fine avrai un progetto completo: una postazione client e un server collegati senza password, con root disabilitato, brute-force mitigato e algoritmi resistenti al calcolo quantistico.<\/p>\n\n\n\n

Perch\u00e9 l’autenticazione SSH con chiavi batte le password<\/h2>\n\n\n\n

Una password, per quanto robusta, \u00e8 un segreto condiviso: viaggia (in forma cifrata) verso il server a ogni login e pu\u00f2 essere indovinata, intercettata via phishing o estratta da un database compromesso. Una chiave SSH funziona in modo radicalmente diverso. La parte privata non lascia mai il tuo computer. Il server conserva solo la chiave pubblica e lancia una sfida matematica che solo chi possiede la chiave privata pu\u00f2 risolvere. Nessun segreto transita sulla rete e non c’\u00e8 nulla da indovinare con la forza bruta.<\/p>\n\n\n\n

I numeri lo confermano. Un attaccante che tenta password contro la porta 22 ha probabilit\u00e0 realistiche di successo contro credenziali deboli o riutilizzate. Contro una chiave Ed25519 dovrebbe risolvere un problema di logaritmo discreto su curva ellittica, un’operazione che resta fuori dalla portata dei computer classici. Aggiungi che con PasswordAuthentication no<\/code> il server smette del tutto di valutare le password, e i bot che riempiono \/var\/log\/auth.log<\/code> ricevono un rifiuto immediato senza nemmeno arrivare alla fase di autenticazione.<\/p>\n\n\n\n

C’\u00e8 anche un fattore di igiene operativa. Le chiavi sono per macchina e per utente: puoi autorizzare il laptop di un collaboratore e revocarlo cancellando una riga da authorized_keys<\/code>, senza cambiare nulla per gli altri. Con ssh-agent<\/code> ti autentichi una volta e riutilizzi la sessione per decine di server, eliminando la tentazione di scegliere password facili da digitare. La chiave privata, protetta da una passphrase, resta cifrata sul disco anche se il portatile viene rubato.<\/p>\n\n\n\n

Come funziona la crittografia a chiave pubblica in SSH<\/h2>\n\n\n\n

SSH usa la crittografia asimmetrica. Quando esegui ssh-keygen<\/code> generi due file matematicamente legati: la chiave privata (per esempio ~\/.ssh\/id_ed25519<\/code>) e la chiave pubblica (~\/.ssh\/id_ed25519.pub<\/code>). Ci\u00f2 che firmi con la privata si verifica solo con la pubblica corrispondente, e dalla pubblica \u00e8 computazionalmente impossibile risalire alla privata.<\/p>\n\n\n\n

Durante la connessione il flusso \u00e8 questo: il client annuncia quale chiave pubblica intende usare, il server controlla che quella chiave sia presente in ~\/.ssh\/authorized_keys<\/code> dell’utente, poi invia una sfida basata sulla sessione corrente. Il client firma la sfida con la chiave privata e rimanda la firma. Il server la verifica con la chiave pubblica registrata. Se la firma \u00e8 valida, l’accesso \u00e8 concesso. Tutto questo avviene dopo che client e server hanno gi\u00e0 negoziato un canale cifrato tramite uno scambio di chiavi (key exchange), quindi anche i metadati dell’autenticazione viaggiano protetti.<\/p>\n\n\n\n

Il concetto \u00e8 lo stesso che protegge le connessioni web e la posta cifrata. Se vuoi approfondire le fondamenta, abbiamo spiegato il meccanismo delle firme digitali<\/a> e il funzionamento di HTTPS e TLS<\/a>, che condividono con SSH la stessa logica di scambio asimmetrico. La differenza pratica \u00e8 che in SSH gestisci tu, manualmente, l’elenco delle chiavi autorizzate su ogni macchina.<\/p>\n\n\n\n

Step 1: Prerequisiti e versioni del 2026<\/h2>\n\n\n\n

Prima di iniziare, allinea l’ambiente. Questo tutorial presuppone due macchine: un client (il tuo laptop, Linux o macOS, oppure Windows con OpenSSH integrato) e un server raggiungibile via rete. Servono accesso amministrativo (sudo<\/code>) sul server e una sessione SSH gi\u00e0 funzionante, anche solo con password, per la configurazione iniziale.<\/p>\n\n\n\n

Componente<\/th>Versione consigliata (2026)<\/th>Note<\/th><\/tr><\/thead>
OpenSSH<\/td>10.3p1 (2 aprile 2026)<\/td>Versione stabile corrente lato client e server<\/td><\/tr>
Ubuntu Server<\/td>24.04 LTS o 26.04 LTS<\/td>Valido anche su Debian 12\/13<\/td><\/tr>
ssh-keygen<\/td>Incluso in OpenSSH 10.3p1<\/td>Genera Ed25519, ECDSA, RSA<\/td><\/tr>
fail2ban<\/td>Pacchetto APT corrente<\/td>Mitigazione brute-force<\/td><\/tr>
Algoritmo chiave<\/td>Ed25519<\/td>RSA 4096 solo per compatibilit\u00e0 legacy<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Verifica la versione di OpenSSH installata sul client e sul server con un solo comando. Le due macchine non devono per forza avere la stessa versione, ma \u00e8 bene che entrambe siano recenti per supportare gli algoritmi moderni.<\/p>\n\n\n\n

ssh -V\n\n# Output atteso (esempio):\n# OpenSSH_10.3p1, OpenSSL 3.5.0  2 Apr 2026<\/code><\/pre>\n\n\n\n
Se vedi una versione compresa tra 8.5p1 e 9.7p1, aggiorna subito: quell’intervallo \u00e8 vulnerabile a CVE-2024-6387 (la falla “regreSSHion”), che in determinate condizioni permette l’esecuzione di codice come root sul server. Su Ubuntu basta sudo apt update && sudo apt upgrade openssh-server openssh-client<\/code>. Le release 9.9p2 (18 febbraio 2025) e successive correggono anche CVE-2025-26465 e CVE-2025-26466.<\/p>\n\n\n\n
Step 2: Ed25519 vs ECDSA vs RSA 4096, quale algoritmo scegliere<\/h2>\n\n\n\n
La scelta dell’algoritmo determina sicurezza, prestazioni e compatibilit\u00e0 della tua chiave per i prossimi anni. Nel 2026 la risposta \u00e8 semplice nella stragrande maggioranza dei casi: Ed25519<\/strong>. \u00c8 basato sulla curva Curve25519, produce chiavi minuscole (circa 32 byte di materiale grezzo), firma e verifica molto rapidamente e ha parametri sicuri fissati per progetto, quindi non puoi configurarlo male.<\/p>\n\n\n\n
Algoritmo<\/th>Sicurezza<\/th>Chiave pubblica<\/th>Prestazioni<\/th>Quando usarlo<\/th><\/tr><\/thead>
Ed25519<\/td>Eccellente<\/td>~32 byte<\/td>Molto veloce<\/td>Scelta predefinita per ogni nuova chiave<\/td><\/tr>
ECDSA P-256<\/td>Buona<\/td>~64 byte<\/td>Veloce<\/td>Solo se Ed25519 non \u00e8 disponibile<\/td><\/tr>
ECDSA P-521<\/td>Molto buona<\/td>Maggiore<\/td>Pi\u00f9 lenta di Ed25519<\/td>Requisiti di policy specifici<\/td><\/tr>
RSA 4096<\/td>Buona<\/td>~512 byte<\/td>Pi\u00f9 lenta<\/td>Sistemi legacy senza supporto ECC<\/td><\/tr>
RSA 2048<\/td>Sufficiente, sconsigliata<\/td>~256 byte<\/td>Pi\u00f9 lenta<\/td>Da evitare per nuove chiavi<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
RSA 4096 resta una scelta conservativa e compatibile, utile quando devi connetterti ad apparati datati o a sistemi embedded che non parlano curve ellittiche. Lo svantaggio \u00e8 la dimensione (chiavi e firme molto pi\u00f9 grandi) e una verifica pi\u00f9 lenta. ECDSA \u00e8 supportato ma offre pochi vantaggi rispetto a Ed25519, e la generazione di parametri sbagliati \u00e8 storicamente pi\u00f9 rischiosa. La regola operativa: genera una chiave Ed25519 e tieni a portata di mano una RSA 4096 solo se incontri un sistema che la pretende.<\/p>\n\n\n\n
Step 3: Generare la coppia di chiavi con ssh-keygen<\/h2>\n\n\n\n
Sul client (non sul server) genera la chiave. L’opzione -a 100<\/code> imposta 100 round di derivazione KDF per proteggere meglio la passphrase, -C<\/code> aggiunge un commento identificativo e -f<\/code> definisce il percorso del file.<\/p>\n\n\n\n
ssh-keygen -t ed25519 -a 100 -f ~\/.ssh\/id_ed25519 -C \"laptop-lavoro-2026\"<\/code><\/pre>\n\n\n\n
Il programma chiede una passphrase. Non lasciarla vuota<\/strong>: la passphrase cifra la chiave privata sul disco, cos\u00ec chi ruba il portatile non ottiene un accesso immediato ai tuoi server. L’output assomiglia a questo.<\/p>\n\n\n\n
Generating public\/private ed25519 key pair.\nEnter passphrase (empty for no passphrase): ********\nEnter same passphrase again: ********\nYour identification has been saved in \/home\/sam\/.ssh\/id_ed25519\nYour public key has been saved in \/home\/sam\/.ssh\/id_ed25519.pub\nThe key fingerprint is:\nSHA256:9pT2k...Qz8 laptop-lavoro-2026<\/code><\/pre>\n\n\n\n
Per un sistema legacy che richiede RSA, il comando equivalente \u00e8 il seguente. L’opzione -o<\/code> forza il formato di chiave privata moderno e -b 4096<\/code> definisce la lunghezza.<\/p>\n\n\n\n
ssh-keygen -t rsa -b 4096 -o -a 100 -f ~\/.ssh\/id_rsa -C \"compatibilita-legacy\"<\/code><\/pre>\n\n\n\n
Ora hai due file. Visualizza la chiave pubblica, l’unica che condividerai: inizia con ssh-ed25519<\/code> ed \u00e8 lunga una sola riga. La chiave privata, id_ed25519<\/code> senza estensione, non deve mai uscire dal client n\u00e9 essere inviata via email o chat.<\/p>\n\n\n\n
cat ~\/.ssh\/id_ed25519.pub\n\n# ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIH9...kQ laptop-lavoro-2026<\/code><\/pre>\n\n\n\n
Step 4: Copiare la chiave pubblica sul server<\/h2>\n\n\n\n
Il modo pi\u00f9 pulito per autorizzare la chiave sul server \u00e8 ssh-copy-id<\/code>. Lo strumento aggiunge la chiave pubblica al file authorized_keys<\/code> dell’utente remoto e imposta automaticamente i permessi corretti. Ti verr\u00e0 chiesta un’ultima volta la password dell’account: \u00e8 normale, la stai usando per installare la chiave.<\/p>\n\n\n\n
ssh-copy-id -i ~\/.ssh\/id_ed25519.pub sam@server.example.com\n\n# Output atteso:\n# Number of key(s) added: 1\n# Now try logging into the machine, with:\n#   \"ssh 'sam@server.example.com'\"<\/code><\/pre>\n\n\n\n
Setup manuale di authorized_keys<\/h3>\n\n\n\n
Se ssh-copy-id<\/code> non \u00e8 disponibile (per esempio su alcuni client Windows), copia la chiave manualmente. Carica il file pubblico con scp<\/code>, poi accodalo ad authorized_keys<\/code> impostando i permessi nella stessa riga.<\/p>\n\n\n\n
scp ~\/.ssh\/id_ed25519.pub sam@server.example.com:\/tmp\/chiave.pub\n\nssh sam@server.example.com 'mkdir -p ~\/.ssh && chmod 700 ~\/.ssh && \\\n  cat \/tmp\/chiave.pub >> ~\/.ssh\/authorized_keys && \\\n  chmod 600 ~\/.ssh\/authorized_keys && rm -f \/tmp\/chiave.pub'<\/code><\/pre>\n\n\n\n
Adesso prova a entrare. Se hai impostato una passphrase, il client la chiede una volta per sbloccare la chiave privata locale, non per autenticarti al server. La connessione deve riuscire senza che il server chieda mai la password dell’account.<\/p>\n\n\n\n
ssh sam@server.example.com\n\n# Enter passphrase for key '\/home\/sam\/.ssh\/id_ed25519': ********\n# Welcome to Ubuntu 26.04 LTS (GNU\/Linux 6.11.0 x86_64)\n# sam@server:~$<\/code><\/pre>\n\n\n\n
Step 5: Configurare ssh-agent e la passphrase<\/h2>\n\n\n\n
Digitare la passphrase a ogni connessione \u00e8 scomodo e spinge verso chiavi senza passphrase, una pessima abitudine. La soluzione \u00e8 ssh-agent<\/code>: un processo che custodisce la chiave decifrata in memoria per la durata della sessione. La sblocchi una volta e l’agente firma le sfide successive senza richiedere altro.<\/p>\n\n\n\n
eval \"$(ssh-agent -s)\"\nssh-add ~\/.ssh\/id_ed25519\nssh-add -l\n\n# Output:\n# Agent pid 4821\n# Identity added: \/home\/sam\/.ssh\/id_ed25519 (laptop-lavoro-2026)\n# 256 SHA256:9pT2k...Qz8 laptop-lavoro-2026 (ED25519)<\/code><\/pre>\n\n\n\n
Su GNOME, KDE e macOS l’agente parte in automatico al login, quindi spesso basta ssh-add<\/code>. Su macOS puoi memorizzare la passphrase nel portachiavi con ssh-add --apple-use-keychain ~\/.ssh\/id_ed25519<\/code>. Evita invece di inoltrare l’agente (ForwardAgent yes<\/code>) verso server non fidati: chi controlla quel server pu\u00f2 usare la tua chiave per la durata della connessione.<\/p>\n\n\n\n
Step 6: Semplificare le connessioni con ~\/.ssh\/config<\/h2>\n\n\n\n
Il file ~\/.ssh\/config<\/code> sul client trasforma comandi lunghi in alias brevi e centralizza le impostazioni per host. Crea o modifica il file e definisci una voce per il tuo server. La direttiva IdentitiesOnly yes<\/code> evita che il client proponga al server tutte le chiavi in elenco, comportamento che pu\u00f2 causare l’errore “Too many authentication failures”.<\/p>\n\n\n\n
Host server-prod\n    HostName server.example.com\n    User sam\n    Port 2222\n    IdentityFile ~\/.ssh\/id_ed25519\n    IdentitiesOnly yes\n    ServerAliveInterval 30\n    ServerAliveCountMax 3<\/code><\/pre>\n\n\n\n
Imposta i permessi del file di configurazione e connettiti con l’alias. Da ora ssh server-prod<\/code> equivale a digitare host, utente, porta e chiave per esteso.<\/p>\n\n\n\n
chmod 600 ~\/.ssh\/config\nssh server-prod<\/code><\/pre>\n\n\n\n
Le direttive ServerAliveInterval<\/code> e ServerAliveCountMax<\/code> inviano un pacchetto di keep-alive ogni 30 secondi e chiudono la sessione dopo tre mancate risposte, evitando connessioni “appese” dietro router che terminano le sessioni inattive.<\/p>\n\n\n\n
Step 7: Hardening di sshd_config sul server<\/h2>\n\n\n\n
Ora blindiamo il demone SSH. Sul server modifica \/etc\/ssh\/sshd_config<\/code> con un editor. Non chiudere la sessione corrente<\/strong>: aprine una seconda per testare le modifiche, cos\u00ec se ti blocchi fuori hai ancora un terminale attivo per correggere.<\/p>\n\n\n\n
Direttiva<\/th>Valore consigliato<\/th>Effetto<\/th><\/tr><\/thead>
PubkeyAuthentication<\/td>yes<\/td>Abilita l’autenticazione a chiave pubblica<\/td><\/tr>
PasswordAuthentication<\/td>no<\/td>Disabilita del tutto le password<\/td><\/tr>
KbdInteractiveAuthentication<\/td>no<\/td>Blocca i prompt interattivi via PAM<\/td><\/tr>
PermitRootLogin<\/td>no<\/td>Vieta il login diretto come root<\/td><\/tr>
MaxAuthTries<\/td>3<\/td>Limita i tentativi per connessione<\/td><\/tr>
AllowUsers<\/td>sam admin<\/td>Consente SSH solo agli account elencati<\/td><\/tr>
Port<\/td>2222<\/td>Riduce il rumore degli scanner automatici<\/td><\/tr>
X11Forwarding<\/td>no<\/td>Disabilita l’inoltro grafico non necessario<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Applica una baseline come la seguente. Su Ubuntu recenti le impostazioni vanno preferibilmente in un file dedicato dentro \/etc\/ssh\/sshd_config.d\/<\/code>, che ha la precedenza sul file principale.<\/p>\n\n\n\n
sudo tee \/etc\/ssh\/sshd_config.d\/99-hardening.conf >\/dev\/null <<'EOF'\nPort 2222\nPubkeyAuthentication yes\nPasswordAuthentication no\nKbdInteractiveAuthentication no\nPermitRootLogin no\nMaxAuthTries 3\nAllowUsers sam admin\nX11Forwarding no\nEOF<\/code><\/pre>\n\n\n\n
Verifica sempre la sintassi prima di riavviare. Il comando sshd -t<\/code> non produce output se la configurazione \u00e8 valida, mentre segnala riga e motivo di un eventuale errore.<\/p>\n\n\n\n
sudo sshd -t && echo \"Configurazione valida\"\nsudo systemctl restart ssh<\/code><\/pre>\n\n\n\n
Step 8: Disabilitare password e accesso root in sicurezza<\/h2>\n\n\n\n
Disattivare le password \u00e8 il momento pi\u00f9 delicato del tutorial. Se la tua chiave non \u00e8 installata correttamente e disabiliti le password, ti chiudi fuori. La procedura sicura \u00e8 questa: con la baseline dello step precedente gi\u00e0 applicata, non chiudere la sessione root o sudo attiva<\/strong> e apri un secondo terminale per testare l’accesso a chiave sulla nuova porta.<\/p>\n\n\n\n
# Dal client, in una NUOVA finestra di terminale:\nssh -p 2222 sam@server.example.com\n\n# Se entri senza che venga chiesta la password dell'account,\n# la chiave funziona e puoi considerare l'hardening riuscito.<\/code><\/pre>\n\n\n\n
Solo dopo aver confermato che il login a chiave funziona nella seconda sessione, puoi chiudere la prima. Se invece ricevi Permission denied (publickey)<\/code>, non disconnetterti: torna alla sessione ancora aperta, controlla authorized_keys<\/code> e i permessi, e correggi prima di proseguire. Molti provider cloud offrono una console seriale o una modalit\u00e0 di recovery che ti salva anche in caso di lockout totale.<\/p>\n\n\n\n
Per i firewall ricorda di aprire la nuova porta. Se usi UFW su Ubuntu, autorizza la 2222 e rimuovi la 22 solo dopo aver verificato l’accesso. Questo approccio per chiavi e accessi limitati si integra con altre difese perimetrali come il server WireGuard VPN<\/a>, che pu\u00f2 esporre SSH solo all’interno di un tunnel cifrato.<\/p>\n\n\n\n
sudo ufw allow 2222\/tcp\nsudo ufw reload\n# Dopo aver verificato il login sulla 2222:\n# sudo ufw delete allow 22\/tcp<\/code><\/pre>\n\n\n\n
Step 9: Algoritmi moderni e crittografia post-quantistica<\/h2>\n\n\n\n
OpenSSH 10.3p1 negozia di default algoritmi solidi, quindi nella maggior parte dei casi non serve fissarli a mano. Anzi, “incollare” liste statiche di KexAlgorithms<\/code> o Ciphers<\/code> \u00e8 rischioso: i default evolvono a ogni release e una lista obsoleta pu\u00f2 indebolire il server o impedirne l’avvio dopo un aggiornamento. La regola del 2026 \u00e8 lasciare i default e intervenire solo per allinearsi a una baseline auditata.<\/p>\n\n\n\n
La novit\u00e0 pi\u00f9 rilevante \u00e8 lo scambio di chiavi resistente al quantum. Le versioni recenti di OpenSSH adottano scambi ibridi come mlkem768x25519-sha256<\/code> (basato su ML-KEM, lo standard NIST derivato da Kyber) e sntrup761x25519-sha256<\/code>. Sono “ibridi” perch\u00e9 combinano un algoritmo post-quantistico con la classica Curve25519: anche se uno dei due cadesse, l’altro tiene. Questo protegge dal modello “harvest now, decrypt later”, in cui un attaccante registra il traffico oggi per decifrarlo quando avr\u00e0 un computer quantistico.<\/p>\n\n\n\n
Se devi davvero pinnare gli algoritmi per una policy interna, mantieni la lista minima e moderna, per esempio cifrari AEAD come chacha20-poly1305@openssh.com<\/code> e aes256-gcm@openssh.com<\/code>. Per capire perch\u00e9 il post-quantum sta entrando ovunque, dalla web alla messaggistica, abbiamo dedicato un’analisi alla crittografia e alle funzioni hash<\/a> che alimentano queste primitive.<\/p>\n\n\n\n
# Verifica gli algoritmi di scambio chiavi supportati dal tuo client:\nssh -Q kex | grep -E 'mlkem|sntrup'\n\n# Output atteso su OpenSSH 10.3p1:\n# sntrup761x25519-sha512@openssh.com\n# mlkem768x25519-sha256<\/code><\/pre>\n\n\n\n
Step 10: Proteggere SSH con fail2ban<\/h2>\n\n\n\n
Con le password disabilitate i bot non possono indovinare credenziali, ma continuano a tempestare il server di tentativi che sporcano i log e consumano risorse. fail2ban analizza \/var\/log\/auth.log<\/code>, individua gli indirizzi IP che falliscono ripetutamente e li banna a livello di firewall per un periodo definito.<\/p>\n\n\n\n
sudo apt update\nsudo apt install fail2ban\n\nsudo tee \/etc\/fail2ban\/jail.d\/sshd.local >\/dev\/null <<'EOF'\n[sshd]\nenabled = true\nport = 2222\nfilter = sshd\nlogpath = \/var\/log\/auth.log\nmaxretry = 5\nfindtime = 10m\nbantime = 1h\nEOF\n\nsudo systemctl restart fail2ban\nsudo systemctl enable fail2ban<\/code><\/pre>\n\n\n\n
Se hai mantenuto SSH sulla porta 22 imposta port = 22<\/code>. Controlla lo stato del jail: vedrai il conteggio dei tentativi falliti e l’elenco degli IP attualmente bannati. Con bantime = 1h<\/code> ogni IP viene escluso per un’ora dopo cinque fallimenti in dieci minuti.<\/p>\n\n\n\n
sudo fail2ban-client status sshd\n\n# Status for the jail: sshd\n# |- Filter\n# |  |- Currently failed: 2\n# |  |- Total failed:     148\n# |  `- File list:        \/var\/log\/auth.log\n# `- Actions\n#    |- Currently banned: 3\n#    `- Total banned:     27<\/code><\/pre>\n\n\n\n
Step 11: Impostare i permessi corretti dei file<\/h2>\n\n\n\n
OpenSSH rifiuta di usare chiavi e file di configurazione con permessi troppo aperti: \u00e8 una protezione contro la lettura da parte di altri utenti del sistema. La causa numero uno dei messaggi “bad permissions” e di molti Permission denied (publickey)<\/code> sono proprio permessi sbagliati su ~\/.ssh<\/code>. Applica questo schema sia sul client sia sul server.<\/p>\n\n\n\n
chmod 700 ~\/.ssh\nchmod 600 ~\/.ssh\/authorized_keys\nchmod 600 ~\/.ssh\/id_ed25519\nchmod 644 ~\/.ssh\/id_ed25519.pub\nchown -R \"$USER:$USER\" ~\/.ssh<\/code><\/pre>\n\n\n\n
File o directory<\/th>Permessi<\/th>Significato<\/th><\/tr><\/thead>
~\/.ssh<\/td>700<\/td>Accesso solo al proprietario<\/td><\/tr>
~\/.ssh\/authorized_keys<\/td>600<\/td>Lettura e scrittura solo proprietario<\/td><\/tr>
~\/.ssh\/id_ed25519 (privata)<\/td>600<\/td>Mai leggibile da altri<\/td><\/tr>
~\/.ssh\/id_ed25519.pub (pubblica)<\/td>644<\/td>Leggibile e condivisibile<\/td><\/tr>
~\/.ssh\/config<\/td>600<\/td>Lettura e scrittura solo proprietario<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
La propriet\u00e0 conta quanto i permessi: tutti i file in ~\/.ssh<\/code> devono appartenere all’utente, non a root. Se hai creato file con sudo<\/code> per errore, il comando chown<\/code> qui sopra rimette a posto il proprietario in modo ricorsivo.<\/p>\n\n\n\n
Step 12: Il progetto completo e la checklist di verifica<\/h2>\n\n\n\n
A questo punto hai un sistema completo e funzionante: client con chiave Ed25519 protetta da passphrase e gestita da ssh-agent<\/code>, server che accetta solo autenticazione a chiave su una porta non standard, root disabilitato e fail2ban a presidio del brute-force. Esegui questa verifica finale per confermare che ogni pezzo sia al suo posto.<\/p>\n\n\n\n
# 1. Le password sono davvero disattivate? (deve fallire subito)\nssh -p 2222 -o PreferredAuthentications=password \\\n    -o PubkeyAuthentication=no sam@server.example.com\n# Atteso: Permission denied (publickey).\n\n# 2. Il login a chiave funziona?\nssh server-prod 'echo OK; hostname; whoami'\n# Atteso: OK \/ nome-server \/ sam\n\n# 3. fail2ban \u00e8 attivo?\nsudo fail2ban-client status sshd<\/code><\/pre>\n\n\n\n
Usa questa checklist come riepilogo del progetto. Se tutte le voci sono soddisfatte, il tuo accesso SSH \u00e8 blindato secondo le pratiche del 2026.<\/p>\n\n\n\n