6.2. TELNET

6.2.1. Architektur und Protokoll

TELNET steht als Abkürzung für TELecommunications NETwork protocol und ist eine der ältesten Internet-Anwendungen.

Zweck dieser Anwendung ist die interaktive Nutzung entfernter Rechner im Textmodus (auch als remote login bezeichnet). Natürlich nutzt man auch mit anderen Anwendungen wie WWW, FTP oder E-Mail entfernte Rechner, kann allerdings dabei in der Regel keine beliebigen Programme auf den entfernten Rechnern ausführen.

Typische Anwendungsfälle für TELNET sind:

Anmerkung:
Häufig erfolgt bei Telnet nur eine sehr schwache Authentifizierung und keine Verschlüsselung der zwischen den Partnern ausgetauschten Daten. In der Regel weist nur der Klient dem Server die Kenntnis eines Paßworts nach, wobei dieses Paßwort meist im Klartext übertragen wird und so relativ leicht abgehört und mißbraucht werden kann. Der Server authentifiziert sich gegenüber dem Klienten im Normalfall überhaupt nicht.

Diese Situation ist speziell in potentiell unsicheren Netzen wie dem Internet unbefriedigend bzw. absolut inakzeptabel. Daher wird Telnet in letzter Zeit für viele Aufgaben zunehmend durch andere Protokolle ersetzt, primär durch die Secure Shell (SSH), die wir uns im Kapitel 8 genauer ansehen werden.

In einer Reihe weiterer Anwendungsfälle steht TELNET "in Konkurrenz" mit anderen Protokollen:

Die Nutzung von TELNET haben Sie sicher bereits vielfach praktiziert. Daher soll es in diesem Abschnitt um Details des Protokolls gehen. Dieses Wissen ist bei der Fehlersuche nützlich und soll Ihnen beim Vorhandensein alternativer Anwendungen die Entscheidung erleichtern.

Die entfernte Nutzung eines Rechners basiert auf dem Client/Server-Konzept:

Der TELNET-Klient interagiert sowohl mit dem Nutzer (Tastatureingaben bzw. Bildschirmausgaben) als auch mit der TCP-Verbindung zum TELNET-Server. Normalerweise werden jegliche Nutzereingaben an den Server geschickt und alle von ihm empfangenen Daten auf dem "Nutzerterminal" dargestellt. Der TELNET-Server dagegen bedient die Applikation, die wir entfernt (remote) nutzen. In Unix-ähnlichen Betriebssystemen erfolgt dies über sog. Pseudoterminals.

Ein Grundanliegen von TELNET war die vollständige Systemunabhängigkeit, so daß sich jeder Host mit jedem "versteht", unabhängig von den angeschlossenen Endgeräten (Terminals). Daher wurde ein sogenanntes network virtual terminal (NVT) - ein zeichenorientiertes Gerät mit Ein- und Ausgabemöglichkeit - mit einer bestimmten Grundfunktionalität eingeführt. Sowohl Klient als auch Server sind dafür verantwortlich, ihre Fähigkeiten auf diese Grundfunktionalität abzubilden.
Als Zeichensatz wird der 7-Bit-Code NVT ASCII verwendet (das höchstwertige Bit jedes Bytes ist 0).

Damit ist eine Basis für die Verständigung zwischen Klient und Server geschaffen. Es existieren jedoch meist etliche optionale Fähigkeiten (z.B. Unterstützung eines bestimmten realen Terminal-Typs), so daß beide Seiten zu Beginn einen gemeinsamen Satz dieser Fähigkeiten aushandeln müssen (option negotiation). Dies erfolgt vollkommen symmetrisch, d.h., jede Seite kann die andere veranlassen, eine bestimmte Option ein- bzw. auszuschalten.

Wir haben gesehen, daß die TELNET-Verbindung nur aus einer einzigen TCP-Verbindung besteht. Die Übertragung von Protokollelementen (z.B. zur Optionsaushandlung) erfordert daher deren Unterscheidung von den Nutzdaten. Zu diesem Zweck wird jedem Protokollelement ein Byte mit dem Wert 255 vorangestellt, das die Bedeutung interprete as command (IAC) besitzt.

Übertragungsmodi

Im wesentlichen werden vom TELNET-Klienten/Server die folgenden Übertragungsmodi unterstützt:

Optionsaushandlung

Bei manchen anderen Protokollen zur entfernten interaktiven Nutzung (z.B. dem heute kaum noch gebräuchlichen X.3-PAD) mußte der Benutzer verschiedene Parameter ("Optionen") von Hand richtig einstellen, was natürlich unbequem und fehleranfällig war. Bei TELNET werden diese Optionen am Anfang "automatisch" ausgehandelt, der Benutzer muß nur noch selten eingreifen (z.B. dann, wenn eine der beteiligten Implementierungen fehlerhaft ist).

Sowohl Klient als auch Server können eine der folgenden Anforderungen an die jeweilige Gegenseite richten:

  1. WILL (der Sender möchte die Option selbst aktivieren)
  2. DO (der Sender möchte, daß der Empfänger die Option aktiviert)
  3. WONT (der Sender möchte die Option selbst deaktivieren)
  4. DONT (der Sender möchte, daß der Empfänger die Option deaktiviert)

Eine Anforderung auf Aktivierung einer Option kann von der Gegenseite angenommen oder abgewiesen werden (Fälle 1 und 2), eine Anforderung auf die Deaktivierung darf dagegen nicht abgelehnt werden (Fälle 3 und 4). Daraus ergeben sich die nachfolgend dargestellten Szenarien:

Sender Empfänger Beschreibung
WILL -->
 
 
<-- DO
Sender möchte eine Option aktivieren; Empfänger stimmt zu
WILL -->
 
 
<-- DONT
Sender möchte eine Option aktivieren; Empfänger lehnt ab
DO -->
 
 
<-- WILL
Sender möchte, daß der Empfänger eine Option aktiviert; Empfänger stimmt zu
DO -->
 
 
<-- WONT
Sender möchte, daß der Empfänger eine Option aktiviert; Empfänger lehnt ab
WONT -->
 
 
<-- DONT
Sender möchte eine Option deaktivieren; Empfänger muß zustimmen
DONT -->
 
 
<-- WONT
Sender möchte, daß der Empfänger eine Option deaktiviert; Empfänger muß zustimmen
Die Aushandlung von Optionen erfordert also die Übertragung von 3 Bytes: das IAC-Byte gefolgt von der Anforderung auf (De)Aktivierung (WILL, DO, WONT, DONT) und die eigentliche Option. Hier sind einige wichtige Optionen:

Optionscode Name Beschreibung
1 echo Entscheidung, welche Seite ein Echo ausführt
3 suppress go ahead NVT folgt normalerweise einem Halbduplexprotokoll. Vollduplex-Endgeräten wird damit ermöglicht, auf das Signal GO AHEAD zu verzichten.
5 status ermöglicht die Verifikation des TELNET-Status aus Sicht der Gegenseite
24 terminal type Terminalemulatoren (z.B. xterm) unterstützen häufig verschiedene Modi. Der Klient sendet dem Server eine Liste verfügbarer Modi, von denen dieser einen auswählt.
32 terminal speed Applikationen sind häufig für bestimmte Übertragungsraten (Modem) optimiert. Mit der Option wird diese Funktionalität auch über TELNET-Verbindungen zur Verfügung gestellt.
34 linemode Übertragungsmodus Linemode einstellen
36 environment variables Mechanismus zur Übertragung von Umgebungsvariablen vom Klienten zum entfernt genutzten Rechner

Weitere Protokollelemente

Neben den Protokollelementen für die Aushandlung von Optionen existieren noch weitere mit der unterschiedlichsten Funktionalität, z.B. folgende:

Name Code Beschreibung
EOF 236 end-of-file, Fileendekennzeichen
SB 250 subnegotiation begin. Einige Optionen erfordern mehr als eine einfache (De)aktivierung. Ein Beispiel ist die Spezifikation des Terminal-Typs. Dessen Bezeichnung ist in Form einer ASCII-Zeichenkette zu übertragen. Derartige Optionen werden in zwei Schritten ausgehandelt. Zuerst einigt man sich darauf, den bzw. die Parameter zu "diskutieren", und anschließend findet die Parameter-Diskussion in einer sog. subnegotiation statt, die jeweils mit dem Kommando SB eingeleitet und mit dem Kommando SE (subnegotiation end) beendet wird.
SE 240 subnegotiation end, Endekennzeichen der subnegotiation einer Option
AYT 246 are you there?, Verbindungstest
GA 249 go ahead, Flußsteuerung im Halbduplex-Betrieb
WILL 251 Optionsaushandlung, siehe oben
WONT 252 Optionsaushandlung, siehe oben
DO 253 Optionsaushandlung, siehe oben
DONT 254 Optionsaushandlung, siehe oben
IAC 255 Datenbyte mit dem Wert 255

© Uwe Hübner, Heino Gutschmidt, Holger Trapp, 24.2.1999