Jordan Gloor / How-To Geek 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.
TELNETCorto per teletype sopra nettoprotocollo di lavoro, è 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, FTPe altri protocolli di quell’epoca sono stati progettati senza alcuna considerazione o percepita necessità di sicurezza.
SSH sta per Ssicuro shell, quindi puoi vedere che la sicurezza è stata un principio guida sin dal suo inizio. Al giorno d’oggi, SSH ha sostituito quasi interamente TELNET.
TELNET è un incubo per la sicurezza con testo in chiaro Il grosso problema con TELNET è che utilizza il testo in chiaro. Non è così crittografare tutto il suo traffico, inclusi nomi utente e password. Tutto ciò che trasmette lungo la rete può essere catturato da sniffing dei pacchetti e leggere, 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 nei loro confronti, gli autori quasi certamente non si aspettavano che le persone lo avrebbero utilizzato più di cinquant’anni dopo, nel panorama IT molto diverso di oggi.
Mentre TELNET merita il suo posto nell’elenco dei programmi importanti che collettivamente ci hanno aiutato a portarci dove siamo oggi, non è qualcosa che dovremmo ancora usare nel mondo di oggi.
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 con privato reti in mente, ma SSH è stato progettato per farvi fronte pubblico retie la necessità di mantenere la privacy e la sicurezza durante il trasferimento dei dati e l’effettuazione di 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 da poco montare un file attacco di forza bruta dove 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 autenticarsi 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 a Git Hub, GitLabE BitBucket repository Git ospitati utilizzando SSH invece delle password.
Un altro vantaggio dell’utilizzo di SSH su TELNET è che SSH può fare tunnel SSH inverso. Ciò richiede che il server stabilisca una connessione con il computer client. Finché 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 Sanguinario. È 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 rattoppato. 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.
Per essere onesti, è successo praticamente un decennio fa, e da allora ci sono stati molti rilasci, miglioramenti, correzioni di bug e revisioni del codice.
IMPARENTATO: I modi migliori per proteggere il tuo server SSH
Dovresti usare SSH o TELNET? È difficile pensare a un motivo per cui avresti bisogno di usare TELNET oggi. Non è lo stesso che 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.
IMPARENTATO: Come connettersi a un server SSH da Windows, macOS o Linux
