Storia di SSH: da telnet a OpenSSH

Dove inizia la storia di SSH

La storia di SSH inizia con le password rubate. Prima del 1995, per accedere a una macchina Unix remota si usavano telnet o rlogin, che trasmettevano entrambi la password sulla rete come testo leggibile. Chiunque potesse monitorare il traffico di rete poteva leggerla e, già all'inizio degli anni '90, le intercettazioni avvenivano proprio su larga scala.

SSH è stata la risposta di una persona a questo problema. Fu scritto nel 1995 e distribuito gratuitamente. Da allora il protocollo è stato ricostruito una volta e il programma utilizzato oggi dalla maggior parte degli utenti è il fork di un fork. Le date riportate di seguito sono importanti, perché ogni passaggio è stato una risposta a un problema specifico.

Che cosa inviavano realmente telnet e rlogin

Telnet è definito nella RFC 854, pubblicata nel maggio 1983 da Jon Postel e Joyce Reynolds. Descrive una sessione terminale trasportata tramite TCP e non include alcun tipo di cifratura. Ogni byte digitato, inclusa la password, viaggia come byte in chiaro che qualsiasi dispositivo lungo il percorso può leggere.

rlogin è nato da Berkeley Unix ed è stato descritto successivamente nella RFC 1282 (BSD Rlogin, B. Kantor, dicembre 1991). Introduceva un rischio ancora maggiore rispetto a una password leggibile: la fiducia basata sull'host. Era possibile configurare un server affinché accettasse connessioni da un host specifico senza richiedere alcuna password. La RFC contiene una sezione intitolata "A Cautionary Tale" che afferma: "Bypassing password authentication from trusted hosts opens ALL the systems so configured when just one is compromised." Inoltre, specifica che la fiducia si basa sui nomi host; quindi una compromissione del DNS (domain name system) o un indirizzo falsificato può aggirarla.

Entrambi i progetti erano adatti alla rete per cui erano stati sviluppati. Le prime reti Ethernet utilizzavano un mezzo condiviso: ogni macchina di un segmento riceveva ogni frame ed era tenuta a ignorare quelli non indirizzati a essa. Una macchina che smetteva di ignorarli, cioè che attivava la modalità promiscua, poteva vedere il traffico degli altri host. Se si aggiunge un'università che assegnava account shell a migliaia di studenti, un singolo account compromesso diventava uno strumento per raccogliere le password di un intero dipartimento.

L’advisory del 1994 senza una correzione

Il 3 febbraio 1994 CERT pubblicò l’advisory CA-94:01, «Ongoing Network Monitoring Attacks». L’advisory riferiva che alcuni intrusi avevano acquisito le credenziali di accesso di decine di migliaia di sistemi su Internet. Lo strumento utilizzato impostava l’interfaccia di rete in modalità promiscua e registrava l’inizio di ogni nuova sessione telnet, rlogin e FTP, cioè la parte che contiene il nome utente e la password.

CERT consigliava ai siti di cambiare la password di ogni account accessibile tramite rete. Se si considerano i protocolli coinvolti, il problema è evidente: la nuova password attraversa la stessa rete in chiaro al primo utilizzo. Non esisteva alcuna correzione applicabile a telnet o rlogin, perché nessuno dei due protocolli prevedeva un meccanismo in cui inserirla.

Perché un attacco di sniffing a Helsinki ha prodotto SSH

Nel 1995 la rete dell'Università di Tecnologia di Helsinki fu colpita da un attacco di sniffing delle password del tipo descritto da CERT. Tatu Ylönen, un ricercatore dell'università, scrisse un'alternativa e la distribuì come freeware nel luglio 1995. La chiamò Secure Shell.

Il progetto si basava su due decisioni architetturali. La sessione era cifrata, quindi chi monitorava il segmento non poteva ricavare informazioni utili. Inoltre, il server dimostrava la propria identità tramite una chiave, consentendo al client di verificare di aver raggiunto la macchina corretta. Questo colmava la vulnerabilità lasciata aperta dall'attendibilità del nome host in rlogin.

SSH si diffuse anche perché i comandi corrispondevano a quelli che gli utenti digitavano già. ssh sostituiva rsh e rlogin, mentre scp sostituiva rcp. Il passaggio richiedeva di modificare un'abitudine, non il flusso di lavoro. Alla fine del 1995 la base utenti aveva raggiunto circa 20,000 utenti in cinquanta paesi. Nel dicembre dello stesso anno, Ylönen fondò SSH Communications Security per sviluppare e vendere il software.

Da una release gratuita a un prodotto commerciale

Quando SSH è diventato un'attività commerciale, la licenza del codice sorgente è cambiata. Le release successive includevano condizioni che limitavano ciò che altri potevano fare con il codice; l'ultima release che chiunque poteva riutilizzare liberamente era ssh 1.2.12. Non c'era nulla di scorretto. Semplicemente, la versione di SSH su cui il resto del mondo poteva basarsi ha smesso di evolversi, mentre lo sviluppo è proseguito in un contesto che il resto del mondo non poteva seguire. Le licenze determinano quale codice continua a essere utilizzabile, un fenomeno descritto in come le licenze open source hanno plasmato l'infrastruttura moderna.

Perché OpenBSD ha effettuato il fork di OpenSSH nel 1999

All'inizio del 1999 Björn Grönvall riprese quell'ultima release libera e iniziò a correggerne i bug. La sua versione si chiamava OSSH e supportava soltanto il protocollo SSH 1.3.

Il progetto OpenBSD adottò OSSH e lo ricostruì. Secondo il resoconto del progetto, Theo de Raadt, Niels Provos, Markus Friedl, Bob Beck, Aaron Campbell e Dug Song si occuparono di ripulire, sottoporre ad audit ed estendere il codice. Il risultato fu OpenSSH 1.2.2, incluso in OpenBSD 2.6 il 1 December 1999.

Perché il fork realizzato da un piccolo progetto di sistema operativo è finito su quasi ogni macchina? Per le esigenze di OpenBSD. OpenBSD distribuisce un sistema di base sottoposto ad audit, progettato per essere sicuro nella configurazione predefinita. Per questo l'accesso remoto cifrato doveva risiedere nel sistema di base e usare una licenza senza restrizioni. Codice sottoposto ad audit e distribuito con una licenza senza restrizioni era esattamente ciò che volevano anche tutti gli altri produttori di sistemi operativi. Damien Miller, Philip Hands e altri avviarono quasi subito un ramo portabile, da cui deriva p in una versione come 10.5p1. OpenBSD sviluppa la versione pulita, mentre il ramo portabile aggiunge il codice di integrazione necessario per tutto il resto. Il modo in cui Unix si è suddiviso nei sistemi che usiamo oggi spiega perché quel codice di integrazione sia necessario.

Il supporto per la seconda versione del protocollo arrivò in seguito. OpenSSH 2.0 fu incluso in OpenBSD 2.7 il 15 June 2000.

Perché SSH-2 è un nuovo protocollo e non un semplice aumento di versione

SSH-1 proteggeva l'integrità del flusso cifrato con CRC-32, un checksum progettato per rilevare gli errori di trasmissione, non per resistere a un attaccante. Nel 1998 Ariel Futoransky ed Emiliano Kargieman di CORE SDI hanno dimostrato le conseguenze. Con le modalità di cifratura CBC o CFB e un controllo CRC-32, un attaccante che conosce anche soltanto 16 byte del testo in chiaro può inserire testo cifrato a propria scelta che il destinatario accetta come autentico, consentendo di eseguire comandi sul server.

La vulnerabilità risiedeva nel protocollo, quindi non poteva essere corretta senza interrompere la compatibilità. Le implementazioni hanno invece aggiunto un rilevatore: codice contenuto in un file chiamato deattack.c, che tentava di riconoscere l'attacco mentre era in corso. Nel febbraio 2001 è stato scoperto che il rilevatore conteneva a sua volta un integer overflow, CVE-2001-0144, che consentiva l'esecuzione remota di codice sui server e sui client che includevano la patch. Un design che non può essere corretto accumula patch, e le patch introducono a loro volta nuovi bug.

SSH-2 è stato definito in un gruppo di lavoro IETF denominato secsh e pubblicato come serie di RFC nel gennaio 2006: l'architettura in RFC 4251, il livello di trasporto in RFC 4253, l'autenticazione degli utenti in RFC 4252 e il livello di connessione in RFC 4254. La suddivisione in livelli è l'aspetto importante, perché consente di sostituire ogni livello separatamente. Gran parte della storia successiva consiste proprio nella sostituzione di questi componenti.

Spiccano due cambiamenti. L'integrità è passata da CRC-32 a un HMAC (codice di autenticazione dei messaggi basato su hash) autenticato con un secret condiviso, quindi un attaccante che non può calcolare il MAC non può falsificare un pacchetto. Inoltre, l'accordo sulla chiave è passato a Diffie-Hellman. In SSH-1 il client sceglieva la chiave di sessione e la inviava cifrata con le chiavi RSA del server, quindi chiunque avesse ottenuto in seguito quelle chiavi private avrebbe potuto decifrare una sessione registrata. Diffie-Hellman deriva un secret nuovo per ogni sessione, che non viene mai trasmesso; di conseguenza, registrare oggi il traffico e sottrarre in seguito la chiave dell'host non permette di ricavare nulla. Questa proprietà è chiamata forward secrecy.

SSH-2 non condivide alcuna compatibilità a livello di protocollo con SSH-1. Per questo è cambiato il numero, invece di incrementare semplicemente la parte decimale.

Perché SSH-1 è stato rimosso invece di essere corretto

La rimozione è avvenuta in tre release di OpenSSH. La versione 7.0, l'11 August 2015, ha disabilitato il protocollo 1 per impostazione predefinita in fase di compilazione. La versione 7.4, il 19 December 2016, ha rimosso il supporto lato server. La versione 7.6, il 3 October 2017, ha eliminato anche il lato client, insieme alle relative opzioni di configurazione e alla documentazione.

Mantenere il protocollo come opzione per le apparecchiature obsolete sarebbe stata la scelta più compatibile, ma il rilevatore CRC-32 spiega perché è stata rifiutata. L'overflow era raggiungibile solo perché il codice del protocollo 1 veniva incluso nella compilazione e si trovava in un percorso che la maggior parte degli amministratori riteneva inattivo nei propri sistemi. Il codice incluso in una release può essere raggiunto. Il codice eliminato non può esserlo.

Perché la prima connessione SSH avvisa della chiave host

La crittografia indica che il traffico è privato. Non indica chi si trova all'altra estremità. Se un attaccante si inserisce nel percorso e risponde al posto del server, si stabilisce una sessione perfettamente crittografata con l'attaccante: è un attacco machine-in-the-middle. SSH risponde usando una chiave host: il server dimostra di possedere la parte privata di una coppia di chiavi e il client confronta quella chiave con il valore registrato l'ultima volta. Per informazioni sul funzionamento della connessione, vedere cosa succede quando si apre una connessione SSH.

Alla prima connessione non esiste una connessione precedente. Il client non ha quindi nulla con cui eseguire il confronto e deve chiederti conferma:

The authenticity of host 'vps.example.com (203.0.113.10)' can't be established.
ED25519 key fingerprint is SHA256:BQ0Qs2jVXhH2lPZ2rM0aQ0mQ8f9pQ0m3nH0oQ1bYqkE.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Rispondendo yes, la chiave viene salvata in ~/.ssh/known_hosts. A ogni connessione successiva il client confronta la chiave con il valore salvato. In caso di differenza, viene visualizzato il messaggio più importante previsto dal programma:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!

Il significato corretto della prima richiesta è che il protocollo ammette il proprio unico punto debole. Trust on first use significa che la sicurezza della prima connessione dipende interamente dalla rete usata per stabilirla. È possibile eliminare questo rischio. Prima della connessione, leggi l'impronta digitale dalla console del provider o dal log di build del server. Puoi pubblicarla nel DNS come record SSHFP (RFC 4255), ma questa soluzione è utile solo se usi DNSSEC. In alternativa, firma le chiavi host con una tua autorità di certificazione (CA), in modo che i client si fidino della CA e non di ogni singola chiave. In pratica, la maggior parte delle persone accetta la richiesta senza verificare la chiave. È importante dirlo chiaramente.

Come le chiavi pubbliche hanno sostituito le password

L’autenticazione a chiave pubblica era disponibile già nelle prime versioni di SSH, ma sono serviti anni perché diventasse la pratica standard. Il meccanismo è asimmetrico: il client dimostra di possedere una chiave privata firmando una richiesta, e la chiave privata non lascia mai il client. Una password funziona al contrario. Anche se SSH la trasmette all’interno del canale cifrato, il server riceve il segreto vero e proprio. Un server compromesso o ostile si ritrova quindi con un’informazione che può riutilizzare contro di voi altrove.

Il secondo motivo è aritmetico. Qualsiasi server con la porta 22 aperta su un indirizzo pubblico riceve tentativi di accesso automatizzati 24 ore su 24, mentre una password è una stringa che si può indovinare. Una chiave non è indovinabile in alcun senso pratico. L’impostazione PasswordAuthentication no elimina questa intera categoria di attacchi, motivo per cui compare in ogni checklist di hardening. Elimina anche il fallback che in passato consentiva di recuperare l’accesso quando una chiave non funzionava. Per questo è importante imparare a distinguere i diversi problemi che restituiscono tutti Permission denied (publickey) prima di essere tu a rimanere senza accesso. Fare a meno delle password significa anche accumulare chiavi. Un agent che ne contiene una dozzina le offre una alla volta finché il server raggiunge il limite di tentativi e chiude la connessione. Questo spiega perché un accesso può non riuscire con Too many authentication failures anche quando la chiave corretta è caricata. La generazione e la rotazione delle chiavi sono descritte in Nozioni di base sulla gestione delle chiavi SSH, mentre le impostazioni lato server sono illustrate in Hardening di SSH su un VPS.

Perché l'elenco degli algoritmi SSH continua a cambiare

Un protocollo a livelli consente di ritirare gli algoritmi senza introdurre un nuovo protocollo. OpenSSH ha sfruttato questa possibilità in modo costante, e le date delle release mostrano il ritmo del cambiamento.

Ed25519 è arrivato in OpenSSH 6.5 il 30 January 2014, insieme al cifrario chacha20-poly1305 e a un formato per le chiavi private protetto da bcrypt. Le firme Ed25519 derivano in modo deterministico il nonce specifico di ogni firma. Di conseguenza, un generatore di numeri casuali debole durante la firma non può esporre la chiave privata. È esattamente il meccanismo che ha permesso di recuperare chiavi private DSA ed ECDSA in incidenti reali.

DSA ha seguito una direzione diversa. OpenSSH 7.0 ha disabilitato ssh-dss chiavi host e utente in fase di esecuzione nel 2015, perché l'algoritmo è limitato a una chiave privata di 160 bit e a SHA-1. La versione 9.8, il 1 July 2024, ha disabilitato DSA in fase di compilazione. La versione 10.0, il 9 April 2025, lo ha rimosso, con le parole del progetto: "completing the deprecation process that began in 2015". Dieci anni dal momento della disabilitazione alla rimozione.

RSA non è scomparso, ma è scomparso il suo vecchio formato di firma. OpenSSH 8.8, il 26 September 2021, ha smesso di accettare per impostazione predefinita le firme RSA generate con SHA-1. Le note di rilascio indicano chiaramente il motivo: SHA-1 è compromesso dal punto di vista crittografico e le collisioni con prefisso scelto erano ottenibili con un costo inferiore a USD 50,000. Se durante la connessione a un vecchio server hai mai visualizzato sign_and_send_pubkey: no mutual signature supported, si tratta di questo cambiamento. La tua chiave è corretta. Non lo è l'algoritmo di firma richiesto dall'altra estremità.

Lo stesso processo interessa ora lo scambio di chiavi, questa volta in anticipo rispetto alla minaccia. Il traffico catturato oggi può essere archiviato e decrittografato anni dopo da chiunque disponga per primo di un computer quantistico sufficientemente potente. Per questo l'accordo sulle chiavi ha dovuto cambiare prima che una macchina simile esista. OpenSSH 9.0, l'8 April 2022, ha reso predefinito uno scambio di chiavi ibrido: sntrup761x25519-sha512@openssh.com combina un algoritmo post-quantistico con lo scambio X25519. Il risultato non è quindi più debole della componente classica se il nuovo algoritmo dovesse rivelarsi inadeguato. OpenSSH 9.9, il 19 September 2024, ha aggiunto mlkem768x25519-sha256, basato su ML-KEM (module lattice key encapsulation mechanism), standardizzato da NIST nel 2024. OpenSSH 10.0 lo ha reso predefinito per l'accordo sulle chiavi, e la pagina post-quantistica del progetto spiega il motivo. OpenSSH 10.1, il 6 October 2025, ha iniziato a mostrare un avviso quando l'altra estremità non supporta questo scambio:

** WARNING: connection is not using a post-quantum key exchange algorithm.
** This session may be vulnerable to "store now, decrypt later" attacks.
** The server may need to be upgraded.

L'avviso è attivo per impostazione predefinita ed è controllato dall'opzione WarnWeakCrypto in ssh_config. Il significato pratico e le azioni da intraprendere quando viene attivato da un server sono descritti in le impostazioni predefinite post-quantistiche per lo scambio di chiavi SSH.

Cosa significa questa cronologia per il server che stai amministrando

Il comando che digiti è cambiato pochissimo dal 1995. Quasi tutto ciò che lo supporta è stato sostituito: il controllo di integrità, lo scambio delle chiavi, gli algoritmi di firma e persino il codice sorgente. Questo è stato possibile solo perché ogni sostituzione si è conclusa con una rimozione intenzionale, e ogni rimozione ha causato problemi a qualcuno.

Per questo, la sicurezza SSH dipende soprattutto dalla versione in uso. I valori predefiniti determinano quali algoritmi vengono proposti, quali vengono rifiutati e quali avvisi vengono visualizzati. Un server obsoleto continua a proporre tutto ciò che la sua release consentiva e continua a negoziare una configurazione meno sicura per supportare i client obsoleti. Ad agosto 2026 la release corrente è OpenSSH 10.5, pubblicata l'11 agosto 2026. La distanza tra questa versione e quella installata su una macchina che nessuno ha aggiornato da tre anni indica l'entità del problema. Verificare la versione rientra in primi dieci minuti su un nuovo VPS.

FAQ

Chi ha creato SSH e perché?

Tatu Ylönen, ricercatore presso la Helsinki University of Technology, ha scritto SSH nel 1995 dopo un attacco di sniffing delle password sulla rete dell'università. Gli strumenti di accesso remoto dell'epoca, telnet e rlogin, trasmettevano le password in chiaro sulla rete. Chiunque monitorasse un segmento condiviso poteva quindi raccogliere le credenziali durante il transito. Nel luglio 1995 ha rilasciato il programma come freeware. Alla fine dello stesso anno contava circa 20,000 utenti in cinquanta paesi e, nel dicembre 1995, Ylönen ha fondato SSH Communications Security.

Qual è la differenza tra SSH-1 e SSH-2?

Sono protocolli diversi e incompatibili a livello di rete. SSH-1 era un unico protocollo monolitico che usava CRC-32 per l'integrità e richiedeva al client di inviare una chiave di sessione cifrata con le chiavi RSA del server. SSH-2 separa le funzioni in un livello di trasporto, un livello di autenticazione e un livello di connessione (RFCs 4251 to 4254, January 2006), usa un HMAC per l'integrità e deriva le chiavi di sessione con Diffie-Hellman. Il traffico registrato rimane quindi riservato anche se la chiave host viene sottratta in seguito. SSH-1 è stato rimosso da OpenSSH in più fasi, fino alla versione 7.6 nell'ottobre 2017.

Perché OpenSSH ha sostituito l'implementazione SSH originale?

Lo sviluppo dell'implementazione originale è confluito in un prodotto commerciale con una licenza restrittiva e l'ultima release riutilizzabile liberamente era ssh 1.2.12. All'inizio del 1999 Björn Grönvall ha ripreso quella release e l'ha trasformata in OSSH. Il team OpenBSD ha poi creato OpenSSH come fork di OSSH e lo ha incluso in OpenBSD 2.6 il 1 dicembre 1999. OpenBSD aveva bisogno di codice sottoposto ad audit e distribuito con una licenza senza restrizioni per il proprio sistema di base. Queste due caratteristiche hanno permesso a tutti gli altri sistemi operativi di distribuire la stessa implementazione tramite il ramo portable.

Perché SSH chiede informazioni sulla chiave host la prima volta che mi connetto?

Perché il client non ha mai visto prima quel server e non ha alcun valore con cui confrontare la chiave. La sola cifratura non consente di distinguere un server legittimo da una macchina che si trova nel mezzo del percorso. SSH identifica quindi i server tramite la chiave e registra ciò che ha rilevato in ~/.ssh/known_hosts. La prima connessione è l'unico momento in cui non esiste un valore memorizzato da verificare. Per questo il client chiede conferma all'utente. Confronta l'impronta con quella ottenuta dalla console del provider o direttamente dal server. Considera ogni successivo messaggio REMOTE HOST IDENTIFICATION HAS CHANGED un evento reale finché non ne hai spiegato la causa.

Perché le chiavi SSH meno recenti smettono di funzionare dopo un aggiornamento?

Perché OpenSSH dismette gli algoritmi secondo un calendario pubblicato. Le chiavi DSA (ssh-dss) sono state disabilitate per impostazione predefinita in OpenSSH 7.0 nel 2015 e rimosse completamente da OpenSSH 10.0 il 9 aprile 2025. Le chiavi RSA continuano a funzionare, ma le firme generate con SHA-1 sono state disabilitate per impostazione predefinita in OpenSSH 8.8 nel settembre 2021. Quando raggiungi un server meno recente, questo problema viene mostrato come sign_and_send_pubkey: no mutual signature supported. Una chiave Ed25519, disponibile da OpenSSH 6.5 nel gennaio 2014, evita entrambi i problemi.