Telnet vs. SSH: Warum Telnet keine Option mehr ist

Telnet vs. SSH ist heute keine akademische Diskussion mehr, sondern eine klare Sicherheitsentscheidung. Telnet war in den Anfangsjahren von IP-Netzwerken praktisch, weil es einfach einzurichten ist und kaum Anforderungen stellt. Genau diese „Einfachheit“ ist jedoch das Problem: Telnet überträgt Inhalte unverschlüsselt – inklusive Benutzernamen, Passwörtern und sämtlicher Kommandos. In modernen Netzen, in denen Zero Trust, Segmentierung, Cloud-Anbindungen und Remote-Arbeitsmodelle zum Alltag gehören, ist das nicht mehr vertretbar. Ein einzelner Mitschnitt im falschen Netzwerksegment reicht aus, um Zugangsdaten zu kompromittieren. SSH (Secure Shell) hingegen verschlüsselt die gesamte Sitzung, bietet Mechanismen zur Server-Authentifizierung und unterstützt zeitgemäße Betriebsprozesse wie Schlüsselverwaltung, starke Authentifizierung und kontrollierte Zugriffsregeln. Dieser Artikel erklärt verständlich, warum Telnet keine Option mehr ist, welche Risiken konkret entstehen, warum „nur im internen Netz“ kein Argument ist und wie Sie die Umstellung auf SSH sauber und praxistauglich umsetzen – unabhängig davon, ob Sie Einsteiger oder bereits fortgeschritten sind.

Was ist Telnet – und wofür wurde es ursprünglich genutzt?

Telnet ist ein Protokoll zur textbasierten Remote-Anmeldung auf entfernten Systemen. Historisch war das Ziel, einen einfachen Terminalzugriff über TCP zu ermöglichen – typischerweise über Port 23. Telnet ist technisch gesehen nicht „kaputt“, sondern schlicht aus einer Zeit, in der Verschlüsselung, Authentizität und Angriffsmodelle wie man-in-the-middle keine zentrale Rolle spielten. Das Protokoll wurde für Funktionalität entworfen, nicht für Sicherheit.

• Typischer Einsatz früher: Remote-Administration von Systemen und Netzwerkgeräten
• Kommunikation: Klartext über TCP
• Port: standardmäßig 23/TCP

Wer den historischen Standard nachlesen möchte, findet ihn über den Anchor-Text RFC 854 (Telnet Protocol Specification).

Was ist SSH – und warum ist es der De-facto-Standard?

SSH (Secure Shell) ist ein Protokoll, das speziell für sichere Remote-Verbindungen entwickelt wurde. SSH verschlüsselt die Sitzung, schützt Anmeldedaten und unterstützt zusätzlich Funktionen wie Schlüsselauthentifizierung, Port-Forwarding und sichere Dateiübertragung (z. B. SCP/SFTP). Im Gegensatz zu Telnet ist Sicherheit kein „Zusatz“, sondern Kernbestandteil des Designs.

• Verschlüsselung: Schutz vor Mitschnitt, Abhören und Datenmanipulation
• Server-Authentifizierung: Prüfung über Host Keys (Schutz vor Fake-Servern)
• Starke Authentifizierung: Passwörter, Public-Key, ggf. MFA/AAA-Integration
• Standard-Port: 22/TCP

Eine technische, herstellerneutrale Grundlage bietet der Anchor-Text RFC 4253 (SSH Transport Layer Protocol).

Der entscheidende Unterschied: Klartext vs. Verschlüsselung

Der wichtigste Grund, warum Telnet keine Option mehr ist, lässt sich in einem Satz zusammenfassen: Telnet sendet alles im Klartext. Das bedeutet: Jede Person oder jedes System, das den Netzwerkverkehr mitschneiden kann, sieht nicht nur den Inhalt der Sitzung, sondern auch die Zugangsdaten. Das ist kein theoretisches Problem, sondern ein Alltagsszenario in vielen Umgebungen.

SSH schützt hingegen die Vertraulichkeit und Integrität der Sitzung. Selbst wenn der Verkehr mitgeschnitten wird, sind die Inhalte für Dritte nicht sinnvoll lesbar. Zusätzlich schützt SSH durch Host-Key-Mechanismen gegen viele Formen von Server-Imitation.

Warum „nur internes Netz“ keine ausreichende Absicherung ist

Das Argument „Telnet läuft nur intern“ klingt beruhigend, ist aber in der Praxis gefährlich. Interne Netze sind nicht automatisch vertrauenswürdig. Häufige Gründe:

• Laterale Bewegung: Ein kompromittierter Client im internen Netz kann Telnet-Verkehr mitschneiden oder missbrauchen.
• Fehlkonfigurationen: VLAN-Leaks, falsch gesetzte ACLs oder versehentliche Trunk-Fehler öffnen interne Pfade.
• Gästenetze und BYOD: Unübersichtliche Endgeräte erhöhen die Wahrscheinlichkeit von Kompromittierungen.
• Remote-Zugänge: VPNs, Jump Hosts und Cloud-Anbindungen erweitern die Angriffsfläche.

Konkrete Risiken von Telnet in modernen Netzwerken

Telnet ist nicht nur „unsicher“, sondern ermöglicht sehr konkrete Angriffswege. Diese Risiken sind im Alltag besonders relevant:

Passwortdiebstahl durch Mitschnitt (Sniffing)

Mit einfachen Tools kann ein Angreifer Telnet-Sessions mitlesen, sofern er an geeigneter Stelle im Netzwerk sitzt. In Switch-Umgebungen kann das durch Fehlkonfigurationen, Mirror-Ports oder kompromittierte Systeme passieren. Da Telnet keine Verschlüsselung nutzt, sind Anmeldedaten sofort verwertbar.

Man-in-the-Middle und Session-Manipulation

Telnet bietet keine starke Gegenwehr gegen MITM-Angriffe. Ein Angreifer kann Verkehr umleiten oder manipulieren und so Kommandos beeinflussen oder Umgebungen ausspionieren. SSH reduziert dieses Risiko durch Verschlüsselung und Host-Key-Prüfung erheblich.

Credential-Reuse als Multiplikator

In vielen Unternehmen werden Zugangsdaten aus Bequemlichkeit wiederverwendet. Sobald ein Telnet-Passwort kompromittiert ist, sind oft mehrere Geräte betroffen. SSH verhindert zwar nicht automatisch Credential-Reuse, reduziert aber das Risiko, dass Passwörter überhaupt abgegriffen werden können.

Fehlende Auditierbarkeit und Compliance-Probleme

Viele Sicherheits- und Compliance-Rahmenwerke erwarten verschlüsselte Administration, starke Authentifizierung und nachvollziehbare Zugriffe. Telnet widerspricht diesem Grundgedanken. Hersteller und Sicherheitsstandards empfehlen daher seit Jahren, unsichere Protokolle zu deaktivieren und sichere Alternativen zu verwenden.

Als herstellerneutrale Orientierung sind die Empfehlungen des US NIST zum Thema sichere Protokolle und Kryptografie über den Anchor-Text NIST Veröffentlichungen zur IT-Sicherheit hilfreich.

Mythen im Praxisbetrieb: „Telnet ist schneller“ und „SSH ist zu kompliziert“

Telnet wirkt häufig „schneller“, weil es keine Verschlüsselung aufbaut. In modernen Geräten und Netzwerken ist dieser Unterschied jedoch in der Regel vernachlässigbar. SSH-Handshakes sind effizient, Hardware ist leistungsfähig, und die Vorteile überwiegen klar.

• Performance: Für CLI-Administration ist der Overhead von SSH selten relevant.
• Komplexität: SSH wirkt nur dann kompliziert, wenn Grundlagen fehlen (Domain-Name, Schlüssel, VTY-Settings).
• Stabilität: SSH ist etabliert, standardisiert und breit unterstützt.

In der Praxis ist SSH zudem oft leichter in saubere Betriebsprozesse integrierbar, etwa durch zentrale Authentifizierung, rollenbasierte Berechtigungen oder Jump-Host-Konzepte.

Telnet vs. SSH im Netzwerkbetrieb: Was ändert sich wirklich?

Der Umstieg auf SSH verändert nicht, wie Sie Geräte administrieren, sondern wie sicher und kontrolliert das passiert. Die CLI-Befehle bleiben gleich, aber die Rahmenbedingungen werden deutlich besser.

• Sichere Transportstrecke: Verschlüsselung schützt Inhalte.
• Authentizität: Host Keys helfen gegen „Fake Devices“ und MITM.
• Kontrollierter Zugriff: SSH lässt sich leichter auf Admin-Netze begrenzen.
• Integration: Bessere Anbindung an AAA, Logging, Monitoring.

So migrieren Sie sauber: Telnet abschalten, SSH aktivieren

Eine erfolgreiche Migration besteht aus zwei Teilen: SSH korrekt einrichten und Telnet konsequent deaktivieren. Der Ablauf sollte möglichst standardisiert erfolgen, damit Sie sich nicht aussperren.

Schrittfolge für ein sicheres Vorgehen

• Management-Erreichbarkeit prüfen (IP, VLAN/SVI, Routing, Gateway).
• Lokalen Benutzer und Enable Secret setzen (oder AAA vorbereiten).
• Domain-Name setzen und RSA-Schlüssel erzeugen.
• SSHv2 aktivieren, VTY auf SSH begrenzen.
• Test per SSH von einem Admin-Client.
• Erst dann Telnet deaktivieren und die Konfiguration speichern.

Beispielkonfiguration auf Cisco IOS/IOS XE: SSH aktivieren und Telnet deaktivieren

Die folgenden Befehle zeigen ein praxistaugliches Basissetup. Passen Sie Hostname, Domain und Passwörter an Ihre Standards an. Wichtig ist vor allem der Teil in den VTY-Lines: transport input ssh sorgt dafür, dass Telnet nicht mehr angenommen wird.

Grundlagen: Hostname, Benutzer, Domain

enable
configure terminal
hostname DEVICE-01
enable secret <SICHERES_PASSWORT>
username admin privilege 15 secret <SICHERES_PASSWORT>
ip domain-name firma.local

RSA-Schlüssel und SSHv2

crypto key generate rsa modulus 2048
ip ssh version 2

VTY absichern: nur SSH erlauben

line vty 0 4
login local
transport input ssh
exec-timeout 10 0

Optional: SSH-Zugriff auf Admin-Netze einschränken

Eine einfache, sehr wirksame Best Practice ist die Begrenzung auf ein Admin-Subnetz:

ip access-list standard ACL-SSH-ADMIN
permit 192.168.50.0 0.0.0.255
deny any

line vty 0 4
access-class ACL-SSH-ADMIN in

Konfiguration prüfen und speichern

show ip ssh
show running-config | section line vty
copy running-config startup-config

Herstellerseitige Details und Varianten finden Sie über den Anchor-Text Cisco SSH-Konfiguration und Troubleshooting.

Was „Telnet abschalten“ in der Praxis bedeutet

Telnet ist auf Cisco-Geräten typischerweise über VTY-Lines erreichbar. Der entscheidende Befehl ist transport input ssh, weil er die erlaubten Protokolle auf SSH begrenzt. Wenn Sie stattdessen transport input telnet ssh oder transport input all verwenden, bleibt Telnet aktiv.

• Telnet deaktivieren: transport input ssh
• Telnet aktiv lassen: transport input telnet ssh oder transport input all

Zusätzlich ist es sinnvoll, unsichere Alt-Konfigurationen zu bereinigen, z. B. alte Line-Passwörter zu entfernen und stattdessen login local oder AAA zu verwenden.

Typische Fehler bei SSH – und warum sie fälschlich Telnet „rechtfertigen“

In manchen Teams bleibt Telnet aktiv, weil SSH „nicht funktioniert“. In fast allen Fällen sind die Ursachen banal und lösbar. Diese Checkliste deckt die häufigsten Punkte ab:

• Domain fehlt: Ohne ip domain-name lässt sich oft kein RSA-Key erzeugen.
• RSA-Key fehlt: Ohne Schlüssel bleibt SSH inaktiv.
• VTY falsch: Telnet ist noch erlaubt oder login passt nicht zur Authentifizierung.
• Management-IP/Routing: Gerät ist nicht erreichbar (SVI down, Gateway fehlt, ACL blockt).
• ACL zu strikt: Admin-Netz wurde falsch definiert, Zugriff wird geblockt.

Eine schnelle Verifikation liefern:

show ip ssh
show running-config | section line vty
show ip interface brief

Best Practices für nachhaltige Remote-Verwaltung

SSH ist der Mindeststandard, aber ein wirklich sicherer Betrieb geht darüber hinaus. Je nach Umgebung sind diese Maßnahmen sinnvoll:

• Admin-Zugriff segmentieren: Management-VLAN oder Management-VRF nutzen, Zugriff nur aus Admin-Netzen.
• Zentrale Authentifizierung: AAA (TACACS+/RADIUS) für Rollen, Nachvollziehbarkeit, zentrale Sperrung.
• Schlüsselbasierte Authentifizierung: Wo möglich, Passwörter ergänzen oder ersetzen.
• Logging und Zeit: Syslog und NTP für korrekte Zeitstempel.
• Session-Timeouts: exec-timeout auf Konsole/VTY setzen.

Als herstellerneutraler Rahmen für Sicherheitsmaßnahmen sind die Empfehlungen des Center for Internet Security über den Anchor-Text CIS Controls ein hilfreicher Bezugspunkt.

Wann Telnet überhaupt noch vorkommt – und wie Sie damit umgehen

In der Realität existiert Telnet manchmal noch, weil Legacy-Geräte oder sehr alte Betriebsprozesse nicht modernisiert wurden. Auch in Laborumgebungen wird Telnet gelegentlich aus Bequemlichkeit genutzt. Das Problem ist weniger, dass Telnet „existiert“, sondern dass es in produktiven Netzen erreichbar bleibt.

• Legacy-Geräte: Wenn SSH nicht unterstützt wird, sollten diese Systeme isoliert werden (separates Segment, restriktive ACLs, Jump Host).
• Lab-Umgebungen: Auch hier ist SSH empfehlenswert, damit Routinen produktionsnah bleiben.
• Übergangsphasen: Telnet nur kurzfristig, streng begrenzt und mit klarer Abschaltfrist.

Wenn Telnet ausnahmsweise temporär benötigt wird, sollte das stets als kontrolliertes Risiko behandelt werden: segmentiert, überwacht, dokumentiert und zeitlich befristet.

Praxis-Checkliste: Telnet endgültig entfernen, SSH sauber etablieren

• Ist die Management-IP korrekt konfiguriert und erreichbar (Ping)?
• Gibt es einen lokalen Admin-User oder AAA für login auf VTY?
• Sind Domain-Name und RSA-Schlüssel gesetzt?
• Ist SSHv2 aktiv (show ip ssh)?
• Steht auf VTY wirklich transport input ssh?
• Ist der Zugriff auf Admin-Netze eingeschränkt (ACL/Access-Class)?
• Wurde nach erfolgreichem Test gespeichert (copy run start)?
• Wird die Änderung in Monitoring/Logging sichtbar (Syslog, Login-Events)?

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.