In che modo SSH è diverso da Telnet?
Riepilogo: TELNET non ha alcuna crittografia, quindi tutto viene trasmesso in chiaro. SSH è crittografato, quindi è privato e sicuro. Ecco perché SSH dovrebbe essere preferito a TELNET.
SSH e TELNET ti consentono entrambi di connetterti a computer remoti in rete e di usarli come se fossi seduto di fronte a loro. Quindi qual è la differenza tra questi due venerabili protocolli e c'è davvero sempre un vantaggio nell'usare SSH su TELNET?
TELNET e SSH: la storia delle origini
Necessità è la madre dell'invenzione. Gli amministratori di sistema avevano bisogno di un modo per accedere e gestire i computer che si trovavano fisicamente altrove. Se era poco pratico o scomodo per l'amministratore posizionarsi davanti al computer, aveva bisogno di un modo per accedere al computer remoto che consentisse loro di impartire comandi proprio come se li stessero digitando in quel computer.
TELNET, abbreviazione di teletype over network protocol, è stato sviluppato nel 1969 come risposta a questo problema. Finché il computer remoto era accessibile dalla rete, consentiva all'amministratore, oa qualsiasi altra persona autorizzata, di connettersi ad esso e utilizzarlo come se stessero premendo fisicamente i tasti della tastiera remota.
SSH è stato creato molto più tardi, nel 1995, come risposta diretta a Telnet e ad altre soluzioni simili. La necessità questa volta era la sicurezza. TELNET, rlogin, FTP e altri protocolli di quell'epoca sono stati progettati senza alcuna considerazione o percepita necessità di sicurezza.
SSH sta per secure shell, quindi puoi vedere che la sicurezza è stata un principio guida sin dal suo inizio. Al giorno d'oggi, SSH ha quasi completamente sostituito TELNET.
TELNET è un incubo per la sicurezza con testo in chiaro
Il grosso problema con TELNET è che utilizza il testo in chiaro. Non crittografa il suo traffico, inclusi nomi utente e password. Tutto ciò che trasmette lungo la rete può essere catturato tramite lo sniffing dei pacchetti e letto, con la massima facilità. Questo è un rischio per la sicurezza anche su una rete locale, a meno che tu non sia l'unico utente. Qualsiasi utente può intercettare il traffico TELNET e ottenere credenziali di accesso alle quali non ha diritto.
Se il computer remoto è fuori sede e richiede una connessione via Internet per raggiungerlo, il problema viene amplificato incommensurabilmente. TELNET era un prodotto del suo tempo e, per essere onesti con loro, gli autori quasi certamente non si aspettavano che le persone lo usassero ben più di cinquant'anni dopo, nel panorama IT molto diverso di oggi.
Mentre TELNET merita il suo posto nell'elenco di importanti programmi che collettivamente ci hanno aiutato a portarci dove siamo oggi, non è qualcosa che dovremmo ancora usare nel mondo di oggi.
In che modo SSH è diverso da TELNET?
A prima vista, TELNET e SSH sono due risposte allo stesso problema. Entrambi ti consentono di accedere a una finestra di terminale su un computer remoto e di impartire comandi ad esso. Ma poiché SSH è stato sviluppato molto più tardi di TELNET, il problema è stato compreso più a fondo e la risposta è stata progettata meglio.
TELNET è stato progettato pensando alle reti private , ma SSH è stato progettato per far fronte alle reti pubbliche e alla necessità di mantenere la privacy e la sicurezza durante il trasferimento dei dati e le connessioni remote.
TELNET utilizza la porta 23 e quel numero di porta non può essere modificato. Per impostazione predefinita, SSH utilizza la porta 22, ma questa può essere configurata e modificata. La configurazione di SSH per l'utilizzo di un numero di porta non ovvio rende più difficile per gli aggressori identificare la porta SSH. Se la porta SSH può essere identificata, è una cosa banale lanciare un attacco di forza bruta in cui migliaia di password raccolte da violazioni dei dati vengono provate a turno da un software automatizzato.
Ancora meglio, SSH può fare a meno delle password. Può utilizzare la crittografia a chiave pubblica per l'autenticazione su computer remoti. Le password non vengono mai trasmesse, perché non è necessario inviarle al computer remoto. La crittografia dei dati e l'autenticazione con chiave SSH consentono a SSH di fornire connessioni e comunicazioni sicure su reti non sicure come Internet.
In effetti, SSH può essere utilizzato per autenticarsi con diversi servizi, non solo con computer remoti che eseguono un server SSH. Ad esempio, puoi accedere ai repository Git ospitati da GitHub, GitLab e BitBucket utilizzando SSH invece delle password.
Un altro vantaggio dell'utilizzo di SSH su TELNET è che SSH può eseguire il tunneling SSH inverso. Ciò richiede che il server stabilisca una connessione con il computer client. Fino a quando l'utente locale non desidera stabilire una connessione al server, la connessione viene ignorata.
Quando il client desidera connettersi al server, l'utente stabilisce una connessione SSH al proprio computer. SSH invia la connessione lungo la connessione già stabilita, al server. Ciò fornisce un tunnel privato all'interno della connessione già crittografata dal server al client.
L'unica vittoria per TELNET è che utilizza meno larghezza di banda. Ma questo non è il 1969 in cui la larghezza di banda era scarsa, e nemmeno SSH è esattamente un maiale di larghezza di banda.
Anche SSH ha avuto i suoi problemi
Sebbene SSH superi TELNET quando si tratta di sicurezza, dobbiamo ricordare che è ancora un software e il software può avere dei bug. Questi bug possono portare a vulnerabilità che possono essere sfruttate dai criminali informatici. Inoltre, gli standard e gli algoritmi di crittografia cambiano nel tempo e vengono sostituiti. Come tutti i software basati sulla crittografia, man mano che le versioni precedenti di SSH invecchiano, possono diventare meno sicure. Ecco perché è importante assicurarsi di utilizzare l'ultima versione di SSH.
La versione di SSH utilizzata nella maggior parte dei computer Linux è OpenSSH, un'implementazione di SSH che si basa sul toolkit e sulle librerie OpenSSL. Nel 2012, la libreria OpenSSL ha introdotto accidentalmente un bug che consentiva a un utente malintenzionato di richiedere una risposta dal server SSL e di specificare quanti dati contenere nella risposta.
Potrebbero richiedere una risposta di (diciamo) 64 KB quando la risposta effettiva non avrebbe richiesto più di 64 byte. La prima sequenza di byte in quei dati sarebbe la risposta autentica e attesa, seguita da qualunque cosa si trovasse nella memoria recentemente utilizzata da OpenSSL. Ciò che era contenuto in quei dati era fortuna, ma poteva contenere informazioni sensibili come cookie di sessione e password o altre informazioni che consentivano a un utente malintenzionato di acquisire chiavi private, ad esempio.
Una volta scoperta, nel 2014, la vulnerabilità è diventata nota come Heartbleed. È stato risolto rapidamente nel software. Tuttavia la vulnerabilità non scompare a quel punto. La vulnerabilità viene completamente annullata solo quando tutti i computer che eseguono il software vulnerabile hanno la versione fissa installata. In altre parole, quando i computer sono stati aggiornati. Poiché molti amministratori sono stati lenti a reagire, l'adozione del software corretto è stata lenta.
Altrettanto preoccupanti sono i due anni tra il 2012, quando è stato introdotto il bug, e il 2014, quando è stato scoperto e risolto. Per quei due anni, ogni server SSH che eseguiva la versione vulnerabile di OpenSSL era a rischio.
Ad essere onesti, è successo praticamente un decennio fa e da allora ci sono stati molti rilasci, miglioramenti, correzioni di bug e revisioni del codice.
Dovresti usare SSH o TELNET?
È difficile pensare a un motivo per cui avresti bisogno di usare TELNET oggi. Non è come dire se esiste uno scenario in cui è sicuro usare TELNET. In una rete autonoma che non è connessa al mondo esterno e sei sicuro che nessuno snifferà il tuo traffico, potresti usare TELNET. Ma non c'è motivo per farlo. Il compromesso sulla sicurezza non può essere giustificato.
SSH è più sicuro e più flessibile: questo è il vantaggio di utilizzare SSH su TELNET. L'implementazione di OpenSSH è gratuita per tutti gli usi, incluso quello commerciale, ed è disponibile per tutti i sistemi operativi più diffusi.