16.9 SSH vs. Telnet: Sicherer Remote-Zugriff einfach erklärt

Wer Netzwerkgeräte wie Router, Switches, Firewalls oder Server remote verwalten möchte, kommt an den Begriffen SSH und Telnet kaum vorbei. Beide Protokolle ermöglichen den Zugriff auf eine Kommandozeile über das Netzwerk. Technisch erfüllen sie damit auf den ersten Blick denselben Zweck. Aus Sicht der Sicherheit gibt es jedoch einen grundlegenden Unterschied: Telnet gilt heute als veraltet und unsicher, während SSH der etablierte Standard für sicheren Remote-Zugriff ist. Für Einsteiger ist dieser Unterschied besonders wichtig, weil er direkt zeigt, wie stark sich die Wahl eines Management-Protokolls auf die Sicherheit eines Netzwerks auswirken kann. Wer Netzwerksicherheit und Gerätehärtung verstehen will, sollte deshalb genau wissen, was SSH und Telnet sind, wie sie funktionieren und warum in modernen Umgebungen praktisch immer SSH verwendet werden sollte.

Was ist Remote-Zugriff im Netzwerk?

Remote-Zugriff bedeutet, dass ein Administrator ein Gerät nicht lokal über die Konsole bedient, sondern über das Netzwerk auf dessen Kommandozeile oder Management-Oberfläche zugreift. Das ist im Alltag unverzichtbar, weil Netzwerkgeräte häufig in Serverschränken, Technikräumen, Rechenzentren oder Außenstellen stehen und nicht jedes Mal physisch erreicht werden können.

Gerade bei Routern und Switches ist der Zugriff per CLI besonders wichtig. Viele Konfigurations- und Prüfaufgaben werden direkt in der Kommandozeile erledigt. Genau dafür wurden Protokolle wie Telnet und SSH entwickelt.

Typische Einsatzbereiche für Remote-Zugriff

• Verwaltung von Routern und Switches
• Fernzugriff auf Linux- oder Unix-Server
• Fehlersuche und Monitoring
• Ändern von Konfigurationen ohne Vor-Ort-Zugang
• Administration von Geräten in Außenstellen

Was ist Telnet?

Telnet ist ein älteres Netzwerkprotokoll, das für textbasierten Remote-Zugriff auf Geräte und Systeme entwickelt wurde. Über Telnet kann ein Administrator eine CLI-Sitzung zu einem Netzwerkgerät aufbauen und Befehle eingeben, als säße er direkt an der Konsole.

Historisch war Telnet über viele Jahre ein Standardwerkzeug in Netzwerken. In modernen Umgebungen ist es jedoch aus Sicherheitsgründen weitgehend abgelöst worden. Der Hauptgrund dafür ist, dass Telnet keine sichere Verschlüsselung für die Sitzung bietet.

Typische Merkmale von Telnet

• Textbasierter Remote-Zugriff
• CLI-Verwaltung über das Netzwerk
• Historisch weit verbreitet
• Heute als unsicher eingestuft

Standardport von Telnet

• Telnet verwendet standardmäßig TCP-Port 23

Was ist SSH?

SSH steht für Secure Shell. Auch SSH ermöglicht textbasierten Remote-Zugriff auf Geräte und Server, verfolgt dabei aber einen ganz anderen Sicherheitsansatz. SSH verschlüsselt die Verbindung zwischen Client und Zielsystem. Dadurch werden Befehle, Zugangsdaten und Sitzungsdaten vor einfachem Mitlesen im Netzwerk geschützt.

SSH ist heute der Standard für sichere CLI-Administration. In Cisco-Netzwerken, auf Linux-Servern, Firewalls und vielen anderen Plattformen wird SSH eingesetzt, wenn Geräte remote verwaltet werden sollen.

Typische Merkmale von SSH

• Sicherer, verschlüsselter Remote-Zugriff
• Schutz von Zugangsdaten und Sitzungsinhalten
• Standard in modernen Netzwerken
• Geeignet für Administration sensibler Systeme

Standardport von SSH

• SSH verwendet standardmäßig TCP-Port 22

Die wichtigste Frage: Warum ist Telnet unsicher?

Der entscheidende Nachteil von Telnet ist, dass das Protokoll die Sitzung im Wesentlichen unverschlüsselt überträgt. Das bedeutet: Benutzername, Passwort und eingegebene Befehle können im Netzwerkverkehr sichtbar sein, wenn ein Angreifer Zugriff auf denselben Übertragungspfad hat oder den Verkehr mitschneiden kann.

In modernen Netzwerken ist das ein erhebliches Risiko. Wer Telnet verwendet, vertraut darauf, dass niemand den Datenverkehr abhört. Genau dieses Vertrauen ist in realen Netzen aber oft nicht gerechtfertigt.

Typische Risiken bei Telnet

• Passwörter können im Klartext übertragen werden
• Befehle und Ausgaben lassen sich mitlesen
• Sitzungen können leichter abgefangen werden
• Keine echte Vertraulichkeit der Management-Kommunikation

Praxisproblem

Wenn ein Administrator sich per Telnet auf einen Switch verbindet und sein Passwort eingibt, kann dieses Passwort unter ungünstigen Bedingungen im übertragenen Verkehr sichtbar werden. Genau das macht Telnet für produktive Netzwerke heute ungeeignet.

Warum SSH als sicher gilt

SSH wurde entwickelt, um genau diese Schwächen zu beseitigen. Die Sitzung wird verschlüsselt aufgebaut, sodass Zugangsdaten und Kommandos nicht einfach im Klartext übertragen werden. Zusätzlich bietet SSH Mechanismen zur Identitätsprüfung des Gegenübers und sorgt damit für deutlich mehr Vertrauenswürdigkeit in der Remote-Verbindung.

Für Einsteiger lässt sich das so zusammenfassen: Telnet funktioniert wie eine offene Unterhaltung im Raum, die jeder mithören kann. SSH funktioniert eher wie eine geschützte, verschlüsselte Leitung.

Wichtige Sicherheitsvorteile von SSH

• Verschlüsselung des gesamten Sitzungsverkehrs
• Schutz von Passwörtern und Befehlen
• Bessere Integrität der Kommunikation
• Geeignet für Administration über unsichere Netzpfade

SSH und Telnet im direkten Vergleich

Beide Protokolle dienen demselben Grundzweck: Remote-Zugriff auf eine Textkonsole. Der Unterschied liegt fast vollständig im Sicherheitsniveau und in der praktischen Eignung für moderne Netzwerke.

Telnet im Vergleich

• Unverschlüsselte Übertragung
• Veraltet aus Sicherheitssicht
• Heute nur noch für spezielle Altumgebungen oder Testnetze denkbar
• Nicht für produktive Administration empfohlen

SSH im Vergleich

• Verschlüsselte Übertragung
• Moderner Standard für CLI-Management
• Geeignet für produktive Netzwerke
• Teil grundlegender Gerätehärtung

Der wichtigste Unterschied in einem Satz

Telnet bietet Remote-Zugriff, aber keine angemessene Sicherheit. SSH bietet Remote-Zugriff mit Sicherheit.

Welche Daten bei Telnet gefährdet sind

Viele Einsteiger denken bei Telnet vor allem an das Passwort. Tatsächlich ist aber die gesamte Sitzung betroffen. Alles, was der Administrator tippt oder was das Gerät zurückliefert, kann bei einer unverschlüsselten Verbindung potenziell mitgelesen werden.

Typisch gefährdete Informationen

• Benutzernamen
• Passwörter
• Konfigurationsbefehle
• Running Configuration
• IP-Adressen, Routen und Sicherheitsparameter
• Fehlersuchdaten und interne Systeminformationen

Warum das kritisch ist

• Ein mitgelesenes Passwort kann direkten Gerätezugang ermöglichen
• Konfigurationsdaten verraten die interne Netzwerkstruktur
• Sicherheitsinformationen können für weitere Angriffe genutzt werden

SSH schützt nicht nur Passwörter

Ein großer Vorteil von SSH ist, dass nicht nur die Anmeldung selbst geschützt wird, sondern die komplette Management-Sitzung. Das ist besonders wichtig, weil ein Administrator während einer Sitzung oft sensible Informationen verarbeitet: VLAN-Strukturen, Routingtabellen, ACLs, VPN-Parameter, Benutzerkonten oder WLAN-Konfigurationen.

SSH verhindert, dass solche Informationen auf dem Transportweg einfach lesbar sind. Genau deshalb gehört SSH heute zu den wichtigsten Basisanforderungen an sichere Netzwerkadministration.

Was SSH konkret schützt

• Anmeldedaten
• CLI-Befehle
• Geräteausgaben
• Vertrauliche Netzwerkinformationen

Typische Einsatzszenarien für SSH

SSH wird in modernen Netzwerken fast überall dort eingesetzt, wo textbasierte Remote-Administration nötig ist. Besonders in Cisco-Umgebungen gehört SSH zu den Standardfunktionen für sichere Geräteverwaltung.

Typische Einsatzbereiche

• Remote-Verwaltung von Routern
• CLI-Zugriff auf Switches
• Administration von Linux-Servern
• Konfigurationsarbeiten auf Firewalls
• Sichere Fernwartung über Management-Netze oder VPN

Warum SSH im Alltag so wichtig ist

• Administration bleibt auch über unsichere oder gemeinsam genutzte Netze geschützt
• Standardisierung im Betrieb wird erleichtert
• Sichere Gerätehärtung wird möglich

Wann Telnet überhaupt noch vorkommt

Telnet ist heute aus Sicherheitsgründen weitgehend verdrängt, kann aber in Altumgebungen, Laboren oder bei sehr alter Hardware noch anzutreffen sein. In Schulungen wird Telnet manchmal noch erwähnt, um den Unterschied zu SSH bewusst zu machen oder historische Protokolle einzuordnen.

In produktiven Netzwerken sollte Telnet jedoch nach Möglichkeit nicht mehr eingesetzt werden. Wenn ein Gerät nur Telnet unterstützt, ist das meist ein Hinweis auf veraltete Technik oder auf ein besonderes Modernisierungsrisiko.

Typische Fälle, in denen Telnet noch auftauchen kann

• Sehr alte Netzwerkgeräte
• Legacy-Umgebungen
• Labors oder Testumgebungen ohne Sicherheitsanspruch
• Schulungszwecke zum Vergleich mit SSH

SSH auf Cisco-Geräten aktivieren

In Cisco-Netzwerken gehört die Aktivierung von SSH zu den Standardaufgaben bei der Gerätehärtung. Damit SSH funktioniert, müssen einige Grundvoraussetzungen geschaffen werden, unter anderem ein Hostname, ein Domain-Name, lokale Benutzerkonten und kryptografische Schlüssel.

Ein einfaches Beispiel für SSH auf einem Cisco-Gerät

hostname R1
ip domain-name firma.local
username admin privilege 15 secret StarkesPasswort123

crypto key generate rsa

line vty 0 4
 transport input ssh
 login local

Was diese Konfiguration bewirkt

• Der Router erhält einen Hostnamen
• Ein Domain-Name wird gesetzt
• Ein lokaler Benutzer mit verschlüsseltem Secret wird erstellt
• Ein RSA-Schlüsselpaar wird erzeugt
• Auf den VTY-Lines ist nur SSH erlaubt
• Die Anmeldung erfolgt über lokale Benutzerkonten

Telnet auf Cisco-Geräten deaktivieren

Ein wichtiger Schritt der Gerätehärtung ist nicht nur das Aktivieren von SSH, sondern auch das konsequente Deaktivieren von Telnet. Sonst bleibt unter Umständen weiterhin ein unsicherer Zugangsweg offen.

Typische sichere VTY-Konfiguration

line vty 0 4
 transport input ssh

Mit diesem Befehl wird Telnet nicht mehr als erlaubtes Eingabeprotokoll akzeptiert. Nur SSH-Sitzungen sind dann noch möglich.

Unsichere Konfiguration zum Vergleich

line vty 0 4
 transport input telnet ssh

Hier wären weiterhin sowohl Telnet als auch SSH erlaubt. Für gehärtete produktive Geräte ist das normalerweise nicht wünschenswert.

Management-Zugriffe zusätzlich absichern

Auch SSH allein ist noch nicht das Ende sinnvoller Absicherung. Ein sicheres Netzwerkdesign beschränkt Management-Zugriffe zusätzlich auf definierte Admin-Netze. Dadurch kann nicht jeder beliebige Benutzer oder Client im Netzwerk überhaupt versuchen, eine SSH-Sitzung zu einem Switch oder Router aufzubauen.

Typische Zusatzmaßnahme mit ACL

access-list 10 permit 10.10.10.0 0.0.0.255

line vty 0 4
 access-class 10 in
 transport input ssh
 login local

In diesem Beispiel dürfen nur Hosts aus dem Netz 10.10.10.0/24 per SSH auf die VTY-Leitungen zugreifen.

Warum diese Einschränkung sinnvoll ist

• Die Angriffsfläche wird reduziert
• Nur das Admin-Netz kann Management-Zugriffe initiieren
• Fehlversuche aus Benutzer- oder Gastnetzen werden verhindert

SSH, Benutzerkonten und Passwortsicherheit

SSH schützt die Verbindung, ersetzt aber keine gute Passwortpraxis. Wenn lokale Admin-Konten schwache oder wiederverwendete Passwörter nutzen, bleibt das Risiko trotz verschlüsselter Verbindung hoch. Deshalb gehören starke Passwörter, individuelle Konten und nach Möglichkeit auch zentrale Authentifizierung oder MFA zum sicheren Gesamtbild dazu.

Wichtige Grundregeln

• Keine Standardpasswörter
• Starke Passwörter oder Passphrasen verwenden
• Gemeinsame Admin-Logins vermeiden
• Zugriffe wenn möglich zentral protokollieren

SSH und Gerätehärtung gehören zusammen

Die Umstellung von Telnet auf SSH ist eine der klassischsten Härtungsmaßnahmen überhaupt. Sie zeigt sehr gut, wie Gerätehärtung funktioniert: Unsichere Altmechanismen werden entfernt und durch sichere Standardverfahren ersetzt. In fast jedem Härtungsleitfaden für Router, Switches und Firewalls gehört dieser Schritt zu den absoluten Basispunkten.

SSH als Teil der Gerätehärtung

• Unsicheres Protokoll Telnet wird deaktiviert
• Verschlüsselter Management-Zugriff wird erzwungen
• Vertraulichkeit der Administrationssitzung wird verbessert
• Management-Zugänge werden bewusster kontrolliert

Typische Missverständnisse zu SSH und Telnet

Missverständnis: Telnet ist nur „etwas älter“, aber sonst okay

Telnet ist nicht einfach nur alt, sondern aus Sicherheitssicht problematisch, weil es keine angemessene Verschlüsselung für moderne Netzwerke bietet.

Missverständnis: SSH ist automatisch sicher genug

SSH ist deutlich sicherer als Telnet, sollte aber zusätzlich durch starke Passwörter, ACLs, Admin-Netze und saubere Gerätehärtung ergänzt werden.

Missverständnis: Im internen Netz ist Telnet unproblematisch

Auch interne Netze sind nicht automatisch vertrauenswürdig. Kompromittierte Clients, Insider-Risiken oder fehlende Segmentierung können Telnet auch intern gefährlich machen.

Missverständnis: Nur das Passwort ist betroffen

Bei Telnet ist die ganze Sitzung betroffen, nicht nur die Anmeldung. Auch Befehle und Ausgaben können im Klartext sichtbar sein.

Ein einfaches Praxisbeispiel

Angenommen, ein Administrator verwaltet einen Switch in einer Außenstelle. In einem veralteten Setup wäre Telnet aktiviert, und das Passwort würde unverschlüsselt durchs Netzwerk laufen. Ein Angreifer mit Zugriff auf einen mitgeschnittenen Netzwerkpfad könnte Benutzername, Passwort und Kommandos potenziell erkennen.

In einem modernen Setup ist derselbe Switch so konfiguriert:

• SSH ist aktiviert
• Telnet ist deaktiviert
• Nur das Admin-VLAN darf die VTY-Leitungen erreichen
• Ein lokaler Benutzer oder zentrales AAA-System wird verwendet

Dieses Beispiel zeigt den praktischen Unterschied sehr deutlich: Nicht die Art der Administration ändert sich, sondern ihr Sicherheitsniveau.

Wichtige Show-Befehle zur Prüfung auf Cisco-Geräten

Nach der Konfiguration sollte überprüft werden, ob SSH aktiv ist und ob Telnet tatsächlich nicht mehr zugelassen wird.

Nützliche Prüfbefehle

show ip ssh
show running-config | section line vty
show running-config | include username
show crypto key mypubkey rsa

Worauf dabei geachtet werden sollte

• Ist SSH aktiviert?
• Existieren kryptografische Schlüssel?
• Ist auf den VTY-Lines nur SSH erlaubt?
• Gibt es sichere lokale Benutzerkonten?

Best Practices für sicheren Remote-Zugriff

• SSH statt Telnet verwenden
• Telnet konsequent deaktivieren
• Management-Zugriffe auf Admin-Netze beschränken
• Starke lokale oder zentrale Authentifizierung nutzen
• Standardkonten vermeiden
• Konfiguration regelmäßig prüfen und dokumentieren
• Remote-Zugriffe protokollieren

Warum der Unterschied zwischen SSH und Telnet so grundlegend ist

Der Vergleich zwischen SSH und Telnet ist ein klassisches Beispiel dafür, wie sich Sicherheit im Netzwerk aus scheinbar kleinen Designentscheidungen ergibt. Beide Protokolle ermöglichen denselben Zugriffstyp, aber nur eines davon schützt die Sitzung angemessen. Genau deshalb ist die Entscheidung für SSH in modernen Netzwerken keine Komfortfrage, sondern eine grundlegende Sicherheitsanforderung.

Wer sichere Remote-Administration umsetzen will, sollte Telnet nicht als Alternative betrachten, sondern als historisches Altprotokoll, das aus produktiven Netzwerken verschwinden sollte. SSH ist heute der klare Standard für sicheren Remote-Zugriff und ein elementarer Bestandteil jeder gehärteten Netzwerkinfrastruktur.

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.