5.7 SSH vs. Telnet: Sicherer Remote-Zugriff verständlich erklärt

SSH und Telnet gehören zu den bekanntesten Protokollen für den Remote-Zugriff auf Netzwerkgeräte, Server und andere Systeme. Gerade für Einsteiger wirken beide zunächst ähnlich, weil sich mit beiden eine textbasierte Verbindung zu einem entfernten Gerät aufbauen lässt. Technisch und sicherheitstechnisch ist der Unterschied jedoch grundlegend. Telnet stammt aus einer Zeit, in der Netzwerke deutlich vertrauensbasierter waren und Sicherheit oft keine zentrale Rolle spielte. SSH wurde dagegen entwickelt, um Remote-Zugriff verschlüsselt und deutlich sicherer bereitzustellen. Für CCNA, Netzwerkpraxis und Cybersecurity ist es deshalb entscheidend, den Unterschied zwischen SSH und Telnet sauber zu verstehen. Wer Netzwerkgeräte administriert, Server verwaltet oder sichere Managementzugänge plant, muss wissen, warum Telnet heute als unsicher gilt und warum SSH zum Standard für sicheren Remote-Zugriff geworden ist.

Warum Remote-Zugriff in Netzwerken so wichtig ist

Netzwerkgeräte werden selten nur lokal administriert

In modernen Netzwerken stehen Router, Switches, Firewalls, Server und andere Systeme oft in Technikräumen, Rechenzentren, Außenstellen oder Cloud-Umgebungen. Eine Administration direkt am Gerät per Tastatur und Bildschirm ist im Alltag unpraktisch oder gar nicht möglich. Genau deshalb werden Protokolle für den Remote-Zugriff benötigt.

• Administratoren konfigurieren Router und Switches aus der Ferne
• Server werden per Remote-CLI verwaltet
• Fehlersuche erfolgt oft über entfernte Managementzugänge
• Änderungen müssen auch standortübergreifend möglich sein

Remote-Zugriff ist also kein Zusatz, sondern ein Kernbestandteil professioneller IT- und Netzwerkarbeit.

Remote-Zugriff ist immer auch ein Sicherheitsrisiko

Genau weil Remote-Zugriff so mächtig ist, gehört er zu den sensibelsten Bereichen einer Infrastruktur. Wer sich remote an einem Netzwerkgerät anmeldet, kann Konfigurationen ändern, Verbindungen beeinflussen, Sicherheitsregeln anpassen oder ganze Dienste stören. Deshalb muss der Zugang besonders gut geschützt werden. Hier zeigt sich der fundamentale Unterschied zwischen SSH und Telnet besonders deutlich.

Was Telnet ist

Telnet ist ein älteres Protokoll für textbasierten Fernzugriff

Telnet ist ein Netzwerkprotokoll, das dazu dient, eine textbasierte Sitzung zu einem entfernten System aufzubauen. Es ermöglicht also im Kern eine entfernte Eingabeaufforderung oder CLI-Verbindung. In der Netzwerktechnik wurde Telnet früher häufig verwendet, um Router, Switches, Server oder andere Systeme über das Netzwerk zu administrieren.

Typische Merkmale von Telnet sind:

• textbasierter Remote-Zugriff
• klassisch über TCP Port 23
• einfache Protokollstruktur
• historisch weit verbreitet

Funktional kann Telnet also durchaus einen Zugriff ermöglichen. Das Sicherheitsproblem liegt nicht in der Grundidee des Remote-Zugriffs, sondern in der Art, wie Telnet Daten überträgt.

Telnet stammt aus einer vertrauensbasierten Zeit

Telnet wurde in einer Zeit entwickelt, in der viele Netzwerke klein, geschlossen und technisch weniger feindlich waren als heute. Die Annahme war vereinfacht: Wer im Netz ist, ist wahrscheinlich legitim. Genau diese Annahme ist in modernen Unternehmensnetzen, WLANs, Cloud-Umgebungen und internetnahen Infrastrukturen nicht mehr tragfähig.

Was SSH ist

SSH ist der sichere Standard für Remote-CLI-Zugriff

SSH steht für Secure Shell. Es erfüllt denselben grundlegenden Zweck wie Telnet, nämlich die entfernte textbasierte Administration, wurde aber von Anfang an mit Sicherheitsmechanismen entworfen. SSH schützt die Verbindung kryptografisch und sorgt dafür, dass Anmeldedaten, Kommandos und Ausgaben nicht einfach im Klartext mitgelesen werden können.

Typische Merkmale von SSH sind:

• verschlüsselter Remote-Zugriff
• klassisch über TCP Port 22
• Schutz von Anmeldedaten
• Schutz der übertragenen Kommandos und Antworten
• Möglichkeit zur Authentifizierung und Identitätsprüfung

SSH ist damit der heutige Standard für sicheren CLI-basierten Fernzugriff in Unternehmensnetzen.

SSH kann mehr als nur eine Terminalverbindung

Auch wenn SSH im CCNA- und Einsteigerkontext meist als sicherer Ersatz für Telnet betrachtet wird, kann es technisch noch mehr leisten. Neben CLI-Zugriff unterstützt SSH auch sichere Dateiübertragung und weitere sichere Verwaltungsfunktionen. Für das Grundverständnis ist aber vor allem wichtig, dass SSH Remote-Zugriff verschlüsselt absichert.

Der wichtigste Unterschied zwischen SSH und Telnet

Telnet überträgt im Klartext, SSH verschlüsselt

Der zentrale Unterschied ist die Behandlung der übertragenen Daten. Telnet sendet Benutzernamen, Passwörter, Kommandos und Ausgaben grundsätzlich unverschlüsselt über das Netzwerk. SSH verschlüsselt diese Daten. Das ist aus Sicht der Netzwerksicherheit der entscheidende Punkt.

• Telnet: Klartextkommunikation
• SSH: verschlüsselte Kommunikation

Gerade in gemeinsam genutzten, schlecht segmentierten oder kompromittierten Netzbereichen ist dieser Unterschied enorm wichtig. Bei Telnet kann ein Angreifer mit geeigneten Möglichkeiten den Datenverkehr oft direkt lesen. Bei SSH ist das deutlich erschwert.

Die Funktion ist ähnlich, das Sicherheitsniveau völlig unterschiedlich

Ein Einsteiger könnte fragen: Wenn beide Protokolle Remote-Zugriff ermöglichen, warum ist dann Telnet so problematisch? Die Antwort ist einfach: Funktionalität allein reicht nicht. In der IT-Sicherheit zählt nicht nur, ob etwas funktioniert, sondern auch, wie sicher es funktioniert. Genau an diesem Punkt fällt Telnet aus heutiger Sicht klar durch, während SSH den Mindeststandard für sichere Administration darstellt.

Warum Telnet als unsicher gilt

Anmeldedaten können mitgelesen werden

Das schwerwiegendste Problem bei Telnet ist, dass Benutzername und Passwort im Klartext übertragen werden. Wer den Verkehr mitschneiden kann, etwa in einem offenen oder kompromittierten Netzsegment, kann diese Daten potenziell direkt auslesen. Das macht Telnet besonders gefährlich für produktive Umgebungen.

Typische Risiken sind:

• Abgriff von Benutzernamen
• Abgriff von Passwörtern
• Übernahme administrativer Zugänge
• Missbrauch kompromittierter Konten

Gerade auf Netzwerkgeräten mit hohem Einfluss ist das ein untragbares Risiko.

Auch Kommandos und Ausgaben sind sichtbar

Nicht nur die Anmeldung, sondern auch alle eingegebenen Befehle und die Antwortausgaben laufen bei Telnet unverschlüsselt über das Netz. Ein Angreifer könnte dadurch nicht nur Zugangsdaten sehen, sondern auch Konfigurationsdetails, IP-Strukturen, Interface-Namen, ACLs, Routinginformationen oder andere sensible Inhalte mitlesen.

Das macht Telnet nicht nur für Authentifizierung, sondern für die gesamte Betriebssicherheit problematisch.

Warum SSH deutlich sicherer ist

SSH schützt Vertraulichkeit und Integrität

SSH bietet Schutz auf mehreren Ebenen. Zum einen wird die Kommunikation verschlüsselt, sodass Inhalte nicht einfach lesbar sind. Zum anderen wird die Integrität der Sitzung besser geschützt, sodass Manipulation des Datenstroms erschwert wird. Aus Sicherheitssicht bedeutet das: Remote-Zugriff ist nicht nur möglich, sondern kontrollierter und vertrauenswürdiger.

• Passwörter werden nicht im Klartext transportiert
• Kommandos werden geschützt übertragen
• Antworten und Ausgaben sind nicht direkt mitlesbar
• Manipulation der Sitzung wird erschwert

SSH unterstützt Identitätsprüfung des Gegenübers

Ein weiterer Sicherheitsvorteil ist, dass SSH Mechanismen bietet, mit denen ein Client die Identität des Zielsystems besser einordnen kann. Damit wird das Risiko reduziert, sich unbemerkt mit einem falschen oder manipulierten System zu verbinden. Auch wenn Einsteiger diese Aspekte oft erst später vertiefen, gehört genau das zu den Gründen, warum SSH deutlich vertrauenswürdiger ist als Telnet.

SSH und Telnet im praktischen Netzwerkalltag

Telnet findet man heute vor allem noch in Altumgebungen oder Laboren

In modernen produktiven Unternehmensnetzen sollte Telnet nach Möglichkeit nicht mehr verwendet werden. Wo es noch auftaucht, handelt es sich häufig um Altgeräte, Legacy-Systeme, Testumgebungen oder spezielle Schulungslabore. Für reale Administration in produktiven Netzen ist Telnet sicherheitstechnisch nicht mehr zeitgemäß.

Typische Gründe, warum Telnet noch existiert:

• alte Geräte ohne moderne Funktionen
• historisch gewachsene Umgebungen
• Labors und Demonstrationen
• fehlende Härtung in veralteten Netzen

SSH ist der Standard für produktive Administration

SSH ist dagegen in professionellen Netzen die bevorzugte Methode für CLI-basierten Fernzugriff. Router, Switches, Linux-Server, Firewalls und viele Managementsysteme setzen standardmäßig auf SSH. In vielen Unternehmen wird Telnet aktiv deaktiviert und nur SSH zugelassen.

Das ist nicht nur Best Practice, sondern grundlegende Sicherheitsanforderung.

Welche Ports verwendet werden

Telnet arbeitet typischerweise auf TCP 23

Wenn in Logs, Firewalls oder ACLs ein Dienst auf TCP Port 23 sichtbar wird, ist das ein starker Hinweis auf Telnet. Aus Sicht der Sicherheitsanalyse ist das relevant, weil Telnet in produktiven Netzen oft besonders kritisch bewertet werden sollte.

• TCP 23 = Telnet

Ein offener Telnet-Port ist fast immer erklärungspflichtig.

SSH arbeitet typischerweise auf TCP 22

SSH verwendet typischerweise TCP Port 22. Wenn ein Gerät diesen Port bereitstellt, bedeutet das jedoch nicht automatisch, dass der Dienst unkritisch ist. Auch SSH muss geschützt, segmentiert und sinnvoll freigegeben werden. Der Unterschied ist: SSH ist der sichere Standardzugang, Telnet dagegen grundsätzlich problematisch.

• TCP 22 = SSH

Warum auch SSH nicht einfach „offen für alle“ sein sollte

Ein sicherer Dienst bleibt ein kritischer Dienst

Ein häufiger Irrtum ist, dass SSH automatisch sicher genug sei, nur weil es verschlüsselt arbeitet. Das ist zu kurz gedacht. SSH schützt die Übertragung, aber ein falsch exponierter SSH-Dienst bleibt ein attraktives Ziel für Angreifer. Ein Managementzugang sollte daher nie unnötig breit erreichbar sein.

Wichtige Grundsätze sind:

• SSH nur aus vertrauenswürdigen Netzen erlauben
• Administrative Zugänge segmentieren
• Starke Authentifizierung verwenden
• Logging und Monitoring aktivieren

Segmentierung und ACLs bleiben entscheidend

Ein guter Sicherheitsansatz besteht darin, SSH nur aus dedizierten Admin-Netzen oder Jump-Hosts zu erlauben. So wird verhindert, dass beliebige Benutzersegmente direkten Zugriff auf Verwaltungsoberflächen erhalten. Genau hier zeigt sich, dass Protokollsicherheit und Netzsegmentierung zusammengehören.

Ein einfaches Beispiel für eine ACL:

ip access-list extended SSH_ADMIN_ONLY
 permit tcp 192.168.50.0 0.0.0.255 any eq 22
 deny tcp any any eq 22
 permit ip any any

Damit wird SSH nur aus einem definierten Netz erlaubt.

Typische Risiken bei unsicherem Remote-Zugriff

Abgriff von Zugangsdaten

Das offensichtlichste Risiko bei Telnet ist der direkte Abgriff von Zugangsdaten im Klartext. In einem kompromittierten Segment, in unsicheren Altumgebungen oder bei lokalen Mitschnittmöglichkeiten ist das ein reales und ernstes Problem.

Folgen können sein:

• Übernahme von Benutzerkonten
• Übernahme von Geräteadministration
• Veränderung von Routing- oder Sicherheitsregeln
• Ausweitung eines Angriffs auf weitere Systeme

Informationsoffenlegung durch ungeschützte Sitzungen

Selbst wenn Zugangsdaten nicht erfolgreich abgegriffen werden, können ungeschützte Telnet-Sitzungen viele wertvolle Informationen offenbaren. Dazu gehören Hostnamen, Schnittstellen, ACLs, Netzbereiche, Routingpfade oder andere administrative Details. Diese Informationen können für spätere Angriffe sehr nützlich sein.

Warum SSH für Datenschutz und Compliance relevant ist

Administrative Kommunikation enthält oft sensible Daten

Remote-Zugriff auf Geräte ist nicht nur aus Betriebssicht wichtig, sondern oft auch datenschutzrelevant. Administrative Sitzungen enthalten Konfigurationsdaten, interne IP-Strukturen, Benutzernamen, Fehlerlogs oder sicherheitsbezogene Informationen. Solche Daten sollten nicht ungeschützt übertragen werden.

SSH trägt dazu bei, diese Informationen auf dem Transportweg zu schützen. Gerade in Unternehmen mit Compliance-Anforderungen ist das ein wichtiger Grund, Telnet konsequent zu vermeiden.

Verschlüsselung ist heute Mindeststandard

In modernen Netzen gilt verschlüsselter Remote-Zugriff nicht als Luxus, sondern als Mindestanforderung. Wer heute noch Telnet in produktiven Bereichen nutzt, betreibt bewusst ein unnötiges Risiko. Genau deshalb ist SSH aus Sicht von Sicherheit, Datenschutz und Betriebssorgfalt der klare Standard.

Cisco-Praxis: SSH statt Telnet konfigurieren und prüfen

SSH auf Cisco-Geräten erkennen und prüfen

In Cisco-Umgebungen lassen sich SSH-Zustände und Konfigurationen mit wenigen Befehlen gut prüfen. Besonders hilfreich sind:

show ip ssh
show running-config
show access-lists
show logging

Diese Befehle zeigen, ob SSH aktiviert ist, welche Konfigurationsgrundlagen bestehen und welche Regeln oder Logs relevant sein könnten.

Grundlegende Erreichbarkeit testen

Auch klassische Erreichbarkeitstests bleiben wichtig, um Managementpfade und Routing zu bewerten:

show ip interface brief
ping 192.168.50.1
traceroute 192.168.50.1

Damit lässt sich prüfen, ob der Pfad zum Managementsystem grundsätzlich funktioniert, bevor der eigentliche Dienstzugriff bewertet wird.

Typische Missverständnisse zu SSH und Telnet

„Telnet funktioniert doch, also ist es okay“

Ein häufiges Missverständnis ist die Gleichsetzung von funktional und sicher. Ja, Telnet kann technisch funktionieren. Genau wie viele andere veraltete Verfahren kann es seinen Zweck erfüllen. Das ist aber kein ausreichendes Kriterium. In der IT-Sicherheit zählt nicht nur, ob ein Dienst erreichbar ist, sondern ob er sicher betrieben werden kann.

„SSH macht alles automatisch sicher“

Auch SSH ist kein Allheilmittel. Ein offener SSH-Dienst mit schwachen Passwörtern, breiter Erreichbarkeit oder fehlendem Monitoring kann weiterhin problematisch sein. SSH ist der richtige technische Standard, muss aber in eine saubere Sicherheitsarchitektur eingebettet werden.

Warum dieses Thema für CCNA und Cybersecurity unverzichtbar ist

SSH vs. Telnet zeigt den Unterschied zwischen alter und moderner Sicherheitslogik

Kaum ein Themenpaar zeigt so deutlich, wie sehr sich Netzwerksicherheit verändert hat. Telnet steht für funktionalen, aber ungeschützten Fernzugriff. SSH steht für dieselbe Grundfunktion, aber mit zeitgemäßem Schutz der Kommunikation. Wer diesen Unterschied versteht, versteht gleichzeitig eine wichtige Grundregel moderner IT: Vertrauen darf nicht vorausgesetzt, sondern muss technisch abgesichert werden.

• Telnet erklärt, warum Klartext problematisch ist
• SSH erklärt, warum Verschlüsselung und Schutz der Sitzung wichtig sind
• beide zusammen zeigen die Entwicklung sicherer Administration

Aus Remote-Zugriff wird ein Security-Grundprinzip

Am Ende geht es nicht nur um zwei Protokolle und ihre Ports. Es geht um die grundsätzliche Frage, wie mächtige Verwaltungszugänge geschützt werden. Wer SSH und Telnet sauber unterscheiden kann, versteht nicht nur Remote-Zugriff besser, sondern auch zentrale Prinzipien von Härtung, Segmentierung und sicherer Netzadministration.

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab/GNS3

Ich biete professionelle Unterstützung im Bereich Netzwerkkonfiguration und Network Automation für private Anforderungen, Studienprojekte, Lernlabore, kleine Unternehmen sowie technische Projekte. Ich unterstütze Sie bei der Konfiguration von Routern und Switches, der Erstellung praxisnaher Topologien in Cisco Packet Tracer, dem Aufbau und Troubleshooting von GNS3- und EVE-NG-Labs sowie bei der Automatisierung von Netzwerkaufgaben mit Netmiko, Paramiko, NAPALM und Ansible. Kontaktieren Sie mich jetzt – klicken Sie hier.

Meine Leistungen umfassen:

• Professionelle Konfiguration von Routern und Switches

• Einrichtung von VLANs, Trunks, Routing, DHCP, NAT, ACLs und weiteren Netzwerkfunktionen

• Erstellung von Topologien und Simulationen in Cisco Packet Tracer

• Aufbau, Analyse und Fehlerbehebung von Netzwerk-Labs in GNS3 und EVE-NG

• Automatisierung von Netzwerkkonfigurationen mit Python, Netmiko, Paramiko, NAPALM und Ansible

• Erstellung von Skripten für wiederkehrende Netzwerkaufgaben

• Dokumentation der Konfigurationen und Bereitstellung nachvollziehbarer Lösungswege

• Konfigurations-Backups, Optimierung bestehender Setups und technisches Troubleshooting

Benötigen Sie Unterstützung bei Ihrem Netzwerkprojekt, Ihrer Simulation oder Ihrer Network-Automation-Lösung? Kontaktieren Sie mich jetzt – klicken Sie hier.