TELNET har ingen kryptering, så allt sänds i klartext. SSH är krypterad, så det är privat och säkert. Det är därför SSH bör användas framför TELNET.
Både SSH och TELNET låter dig ansluta till fjärranslutna datorer i nätverk och använda dem som om du sitter framför dem. Så vad är skillnaden mellan dessa två ärevördiga protokoll, och finns det verkligen alltid en fördel med att använda SSH framför TELNET?
TELNET och SSH: Ursprungsberättelsen
Nödvändighet är uppfinningens moder. Systemadministratörer behövde ett sätt att komma åt och hantera datorer som fysiskt fanns någon annanstans. Om det var opraktiskt eller obekvämt för administratören att placera sig framför datorn, behövde de ett sätt att komma åt fjärrdatorn som gjorde det möjligt för dem att utfärda kommandon precis som om de skulle skriva in dem i den datorn.
TELNET, förkortning för teletype over network protocol, utvecklades 1969 som svaret på det problemet. Så länge fjärrdatorn var tillgänglig för nätverket tillät den administratören, eller någon annan behörig person, att ansluta till den och använda den som om de fysiskt tryckte på tangenterna på fjärrtangentbordet.
SSH skapades mycket senare—år 1995—som ett direkt svar på Telnet och andra liknande lösningar. Nödvändigheten denna gång var säkerhet. TELNET, rlogin, FTP och andra protokoll från den eran designades utan hänsyn till, eller upplevt behov av, säkerhet.
SSH står för secure sh< /strong>ja, så du kan se att säkerhet var en vägledande princip från starten. Nuförtiden har SSH nästan helt ersatt TELNET.
TELNET Is a Plaintext Security Nightmare
Det stora problemet med TELNET är att det använder klartext. Den krypterar inte någon av dess trafik, inklusive användarnamn och lösenord. Allt det sänder längs nätverket kan fångas genom paketsniffning och läsas, med största lätthet. Detta är en säkerhetsrisk även på ett lokalt nätverk, såvida du inte är den enda användaren. Alla användare kan fånga upp TELNET-trafik och få inloggningsuppgifter som de inte har rätt till.
Om fjärrdatorn är utanför platsen och kräver en anslutning över internet för att nå den, förstoras problemet oändligt mycket. TELNET var en produkt av sin tid, och för att vara rättvis mot dem förväntade sig författarna nästan säkert inte att folk skulle använda det mer än femtio år senare, i dagens väldigt annorlunda IT-landskap.
Även om TELNET förtjänar sin plats på listan över viktiga program som tillsammans hjälpte till att ta oss dit vi är idag, är det inte något som vi fortfarande borde använda i dagens värld.
Hur skiljer sig SSH från TELNET?
På första sidan är TELNET och SSH två svar på samma problem. De låter dig båda komma åt ett terminalfönster på en fjärrdator och utfärda kommandon till det. Men eftersom SSH utvecklades så mycket senare än TELNET förstod man problemet bättre och svaret var bättre utformat.
TELNET utformades med privata nätverk i åtanke, men SSH designades för att hantera offentliga nätverk , och behovet av att upprätthålla integritet och säkerhet när du överför data och gör fjärranslutningar.
TELNET använder port 23 och det portnumret kan inte ändras. Som standard använder SSH port 22, men detta kan konfigureras och ändras. Att konfigurera SSH för att använda ett otydligt portnummer gör det svårare för angripare att identifiera SSH-porten. Om SSH-porten kan identifieras är det en trivial sak att genomföra en brute-force-attack där tusentals lösenord som samlats in från dataintrång prövas i tur och ordning med automatiserad programvara.
Ännu bättre, SSH kan avstå från lösenord helt och hållet. Den kan använda kryptering med offentlig nyckel för att autentisera till fjärrdatorer. Lösenord överförs aldrig alls, eftersom det inte finns något behov av att skicka dem till fjärrdatorn. Dess datakryptering och SSH-nyckelautentisering gör att SSH kan leverera säkra anslutningar och kommunikationer över osäkra nätverk som internet.
Faktum är att SSH kan användas för att autentisera med olika tjänster, inte bara fjärrdatorer som kör en SSH-server. Till exempel kan du komma åt Git-förråden som är värd för GitHub, GitLab och BitBucket med SSH istället för lösenord.
RELATERATSka du använda HTTPS eller SSH för Git?
En annan fördel med att använda SSH över TELNET är att SSH kan utföra omvänd SSH-tunnling. Detta kräver att servern upprättar en anslutning till klientdatorn. Tills den lokala användaren vill göra en anslutning till servern ignoreras anslutningen.
När klienten vill ansluta till servern upprättar användaren en SSH-anslutning till sin egen dator. SSH skickar anslutningen ner den redan etablerade anslutningen, till servern. Detta ger en privat tunnel inuti den redan krypterade anslutningen från servern till klienten.
Den enda vinsten för TELNET är att den använder mindre bandbredd. Men det här är inte 1969 där bandbredden var knapp, och SSH är inte precis ett bandbreddssvin heller.
SSH har haft sina problem , också
Även om SSH överträffar TELNET när det kommer till säkerhet, måste vi komma ihåg att det fortfarande är programvara och programvara kan ha buggar. Dessa buggar kan leda till sårbarheter som kan utnyttjas av cyberbrottslingar. Dessutom ändras krypteringsstandarder och algoritmer med tiden och ersätts. Liksom all krypteringsbaserad programvara kan de bli mindre säkra när äldre versioner av SSH åldras. Det är därför det är viktigt att se till att du använder den senaste versionen av SSH.
Den version av SSH som används i de flesta Linux-datorer är OpenSSH, en implementering av SSH som bygger på OpenSSL-verktygslådan och biblioteken. År 2012 introducerade OpenSSL-biblioteket av misstag en bugg som gjorde att en angripare kunde begära ett svar från SSL-servern och ange hur mycket data som ska innehålla i svaret.
De kunde begära ett svar på (säg) 64KB när det faktiska svaret inte skulle ha behövt mer än 64 byte. Den första sekvensen av byte i den datan skulle vara det äkta, förväntade svaret, följt av vad som än råkade finnas i minnet som nyligen användes av OpenSSL. Det som fanns i den datan var pot luck, men den kunde innehålla känslig information som sessionscookies och lösenord, eller annan information som till exempel gjorde det möjligt för en angripare att skaffa privata nycklar.
När den upptäcktes, 2014, blev sårbarheten känd som Heartbleed. Det fixades snabbt i mjukvaran. Men sårbarheten försvinner inte vid den tidpunkten. Sårbarheten upphävs först helt när alla datorer som kör den sårbara programvaran har den fasta versionen installerad. Med andra ord när datorerna har lappats. Eftersom många administratörer var långsamma med att reagera, var upptaget av den fasta programvaran långsam.
Också oroande är de två åren mellan 2012 när buggen introducerades och 2014 när den upptäcktes och åtgärdades. Under dessa två år var varje SSH-server som körde den sårbara versionen av OpenSSL i riskzonen.
För att vara rättvis hände det för nästan ett decennium sedan, och sedan dess har det skett många utgåvor, förbättringar, buggfixar och kodrecensioner.
RELATERAT: De bästa sätten för att säkra din SSH-server
Ska du använda SSH eller TELNET?
Det är svårt att komma på en anledning till att du skulle behöva använda TELNET idag. Det är inte detsamma som att säga att det finns något scenario där det är säkert att använda TELNET. I ett fristående nätverk som inte är anslutet till omvärlden, och du är säker på att ingen kommer att paketsniffa din trafik, kan du använda TELNET. Men det finns ingen anledning till det. Säkerhetsavvägningen kan inte motiveras.
SSH är säkrare och mer flexibelt—det är fördelen med att använda SSH över TELNET. OpenSSH-implementeringen är gratis för all användning, inklusive kommersiell, och är tillgänglig för alla populära operativsystem.
RELATERAT: Hur man ansluter till en SSH-server från Windows, macOS , eller Linux
LÄS NÄSTA
- › Googles Pixel-telefoner har nya kamera- och hälsofunktioner
- › 8 korrigeringar för en andra bildskärm som inte upptäcks i Windows
- › Amazon kommer inte att låta dig köpa Kindle eller tryckta tidningar längre
- › Kodi 20.1 has Arrived: Here’s What’s New
- › Detta Anker-batteri är under återkallelse för brandrisk
- › De bästa VPN-tjänsterna för spel 2023