SSH: proteggere l’accesso remoto

SSH-1, il protocollo Secure Shell originale, conteneva una falla progettuale fondamentale che consentiva a un attaccante attivo di inserire dati arbitrari in una sessione cifrata senza essere rilevato. SSH-2, una completa riprogettazione del protocollo pubblicata nel 2006 come RFC 4251-4254, ha risolto queste debolezze con protocolli separati per i livelli di trasporto, autenticazione e connessione, oltre a un controllo dell'integrità più robusto tramite HMAC. SSH-1 è deprecato e nessun server moderno dovrebbe abilitarlo.

Il protocollo del livello di trasporto SSH gestisce lo scambio iniziale delle chiavi e stabilisce un canale cifrato e protetto da alterazioni. Negozi­a gli algoritmi per lo scambio delle chiavi (in genere ECDH), l'autenticazione dell'host (in genere Ed25519 o RSA), la cifratura simmetrica (in genere AES-256-CTR o ChaCha20-Poly1305) e il MAC (in genere HMAC-SHA2-256). Ogni pacchetto successivo viene cifrato e sottoposto a una verifica di integrità usando gli algoritmi negoziati.

Una volta protetto il livello di trasporto, il livello di autenticazione dell'utente negozia il modo in cui l'utente dimostra la propria identità al server. Tre metodi comuni sono la password (l'utente digita una password, che viene inviata cifrata attraverso il livello di trasporto), la chiave pubblica (l'utente dimostra di possedere una chiave privata corrispondente a una chiave pubblica autorizzata sul server) e GSSAPI (integrazione del single sign-on Kerberos per gli ambienti aziendali).

Il livello di connessione SSH multiplexa più canali logici su un'unica connessione di trasporto cifrata. Una tipica sessione SSH ha un canale per la shell interattiva. Canali aggiuntivi supportano l'inoltro delle porte, l'inoltro X11 e il trasferimento di file SFTP, condividendo tutti la stessa connessione autenticata e cifrata. Le richieste di canale consentono al client di richiedere uno pseudoterminale, impostare variabili d'ambiente o eseguire un comando specifico.

Al primo collegamento a un server SSH, il client riceve la chiave host del server e deve decidere se considerarla attendibile. La politica predefinita è Trust On First Use (TOFU): all'utente viene chiesto di verificare l'impronta digitale della chiave (in genere mostrata come un hash quale SHA256:...) e, se accettata, questa viene memorizzata nel file known_hosts. Nei collegamenti successivi, la chiave memorizzata viene confrontata con quella presentata dal server e una mancata corrispondenza attiva un severo avviso su potenziali attacchi man-in-the-middle.

Il file known_hosts, memorizzato in ~/.ssh/known_hosts, mantiene un database delle chiavi host dei server indicizzate per nome host e indirizzo IP. Ogni voce associa l'indirizzo di un server alla sua chiave pubblica. Se la chiave di un server cambia, magari perché il server è stato reinstallato oppure perché un attaccante lo sta impersonando, SSH rifiuta la connessione e visualizza un avviso. Gli amministratori usano l'autenticazione degli host basata su certificati per evitare decisioni di attendibilità basate su TOFU su larga scala.

L'autenticazione a chiave pubblica memorizza la chiave pubblica dell'utente in ~/.ssh/authorized_keys sul server. Quando l'utente si connette, il server invia una richiesta di autenticazione cifrata con la chiave pubblica; solo chi possiede la chiave privata corrispondente può rispondere correttamente, dimostrando la propria identità senza trasmettere la chiave privata o una password. È più sicura delle password perché le chiavi private non vengono mai inviate sulla rete e non possono essere sottratte tramite phishing.

Tre famiglie di algoritmi per le chiavi SSH sono comunemente utilizzate. Le chiavi RSA da 3072 o 4096 bit sono compatibili con tutti i server. ECDSA usando la curva NIST P-256 è più veloce di RSA a parità di sicurezza, ma i parametri di sicurezza di P-256 sono stati oggetto di esame critico. Ed25519, basato sull'Edwards-curve Digital Signature Algorithm, è la raccomandazione moderna: chiavi da 256 bit rapide e compatte, solide proprietà di sicurezza e nessuna particolare criticità legata ai parametri.

Tatu Ylönen, un ricercatore finlandese presso l'Università di Tecnologia di Helsinki, sviluppò SSH nel 1995 dopo che un attacco di sniffing delle password alla rete della sua università aveva esposto centinaia di credenziali. Scelse la porta 22 perché si trovava tra telnet (23) e ftp (21). SSH sostituì entrambi i protocolli insicuri. Ylönen fondò SSH Communications Security e in seguito pubblicò SSH-2 come standard aperto attraverso l'IETF. OpenSSH, la principale implementazione libera, fu creata dal progetto OpenBSD nel 1999.

L'agent SSH è un processo in background che conserva in memoria le chiavi private decrittografate, consentendo il single sign-on su più server senza dover reinserire la passphrase. L'agent forwarding (opzione -A) estende questa funzionalità inoltrando la connessione dell'agent ai server remoti e consentendo l'accesso con un solo salto ai server interni. Tuttavia, l'agent forwarding costituisce un rischio per la sicurezza: un server remoto compromesso può usare l'agent inoltrato per autenticarsi come se foste voi presso altri server. È preferibile usare ProxyJump invece dell'agent forwarding.

Una configurazione SSH sicura include la disabilitazione dell'accesso root (PermitRootLogin no), la disabilitazione dell'autenticazione tramite password (PasswordAuthentication no) a favore del solo uso di chiavi pubbliche, l'uso di chiavi host Ed25519, l'abilitazione esclusiva del protocollo SSH-2, la configurazione di timeout per le sessioni inattive, la limitazione degli utenti autorizzati con AllowUsers o AllowGroups e la modifica della porta predefinita come misura di offuscamento per ridurre il rumore delle scansioni automatizzate. Fail2ban o strumenti simili bloccano gli indirizzi IP che registrano ripetuti tentativi falliti.

Perché l'autenticazione SSH a chiave pubblica è considerata più sicura dell'autenticazione tramite password?

SSH-2 ha sostituito SSH-1, affetto da una falla progettuale, con livelli separati di trasporto, autenticazione e connessione. Il livello di trasporto negozia la cifratura e l'integrità. L'autenticazione dell'utente supporta password, chiavi pubbliche e GSSAPI. La verifica della chiave host usa TOFU e known_hosts. Ed25519 è l'algoritmo per le chiavi raccomandato. L'agent forwarding costituisce un rischio per la sicurezza: utilizzate invece ProxyJump. L'hardening include la disabilitazione dell'accesso root e dell'autenticazione tramite password.