3. Remote Login - TELNET-Protokoll
3.1 EINFÜHRUNG
Telnet ist das Standard-Internet-Anwendungsprotokoll für Remote-Login. Es bietet die Kodierungsregeln, um die Tastatur/Anzeige eines Benutzers auf einem Client-System („Benutzer") mit einem Befehlsinterpreter auf einem entfernten Serversystem zu verbinden. Eine Teilmenge des Telnet-Protokolls ist auch in andere Anwendungsprotokolle eingebettet, z. B. FTP und SMTP.
Telnet verwendet eine einzelne TCP-Verbindung, und sein normaler Datenstrom (Modus „Netzwerk-Virtual-Terminal" oder „NVT") ist 7-Bit-ASCII mit Escape-Sequenzen zur Einbettung von Steuerfunktionen. Telnet ermöglicht auch die Aushandlung vieler optionaler Modi und Funktionen.
Die primäre Telnet-Spezifikation befindet sich in RFC-854 [TELNET:1], während die Optionen in vielen anderen RFCs definiert sind; siehe Abschnitt 7 für Referenzen.
3.2 PROTOKOLL-DURCHGANG
3.2.1 Optionsaushandlung: RFC-854, S. 2-3
Jede Telnet-Implementierung muss (MUST) Mechanismen zur Optionsaushandlung und Unteraushandlung enthalten [TELNET:2].
Ein Host muss (MUST) die Regeln von RFC-854 sorgfältig befolgen, um Schleifen bei der Optionsaushandlung zu vermeiden. Ein Host muss (MUST) eine nicht unterstützte Option ablehnen (d. h. mit WONT/DONT auf DO/WILL antworten). Die Optionsaushandlung sollte (SHOULD) während der gesamten Lebensdauer einer Telnet-Verbindung weiterhin funktionieren (auch wenn alle Anfragen abgelehnt werden).
Wenn alle Optionsaushandlungen fehlschlagen, muss (MUST) eine Telnet-Implementierung standardmäßig ein NVT sein und es unterstützen.
DISKUSSION:
Auch wenn anspruchsvollere „Terminals" und unterstützende Optionsaushandlungen zur Norm werden, müssen alle Implementierungen darauf vorbereitet sein, ein NVT für jede Benutzer-Server-Kommunikation zu unterstützen.
3.2.2 Telnet Go-Ahead-Funktion: RFC-854, S. 5, und RFC-858
Auf einem Host, der niemals den Telnet-Befehl Go Ahead (GA) sendet, muss (MUST) der Telnet-Server versuchen, die Option Suppress Go Ahead auszuhandeln (d. h. „WILL Suppress Go Ahead" senden). Ein Benutzer- oder Server-Telnet muss (MUST) immer die Aushandlung der Option Suppress Go Ahead akzeptieren.
Wenn es ein Vollduplex-Terminal steuert, für das GA keine Bedeutung hat, kann (MAY) eine Benutzer-Telnet-Implementierung GA-Befehle ignorieren.
DISKUSSION:
Halbduplex-Terminals („gesperrte Tastatur") mit zeilenweiser Eingabe, für die der Go-Ahead-Mechanismus entwickelt wurde, sind weitgehend von der Bildfläche verschwunden. Es hat sich herausgestellt, dass es schwierig ist, das Senden des Go-Ahead-Signals in vielen Betriebssystemen zu implementieren, selbst in einigen Systemen, die native Halbduplex-Terminals unterstützen. Die Schwierigkeit besteht typischerweise darin, dass der Telnet-Servercode keinen Zugriff auf Informationen darüber hat, ob der Benutzerprozess blockiert und auf Eingaben von der Telnet-Verbindung wartet, d. h. er kann nicht zuverlässig bestimmen, wann ein GA-Befehl gesendet werden soll. Daher senden die meisten Telnet-Server-Hosts keine GA-Befehle.
Die Wirkung der Regeln in diesem Abschnitt besteht darin, dass jedes Ende einer Telnet-Verbindung die Verwendung von GA-Befehlen ablehnen kann.
Es gibt eine Klasse von Halbduplex-Terminals, die noch kommerziell wichtig ist: „Dateneingabeterminals", die auf Vollbild-Weise interagieren. Die Unterstützung von Dateneingabeterminals mit dem Telnet-Protokoll erfordert jedoch nicht das Go-Ahead-Signal; siehe Abschnitt 3.3.2.
3.2.3 Steuerfunktionen: RFC-854, S. 7-8
Die Liste der Telnet-Befehle wurde um EOR (End-of-Record) mit Code 239 erweitert [TELNET:9].
Sowohl Benutzer- als auch Server-Telnets können (MAY) die Steuerfunktionen EOR, EC, EL und Break unterstützen und müssen (MUST) AO, AYT, DM, IP, NOP, SB und SE unterstützen.
Ein Host muss (MUST) in der Lage sein, alle Telnet-Steuerfunktionen, die er nicht unterstützt, zu empfangen und zu ignorieren.
DISKUSSION:
Beachten Sie, dass ein Server-Telnet die Telnet-IP-Funktion (Interrupt Process) unterstützen muss, auch wenn der Server-Host eine entsprechende In-Stream-Funktion hat (z. B. Control-C in vielen Systemen). Die Telnet-IP-Funktion kann stärker sein als ein In-Stream-Interrupt-Befehl, wegen des Out-of-Band-Effekts von TCP-Urgent-Daten.
Die EOR-Steuerfunktion kann verwendet werden, um den Stream zu begrenzen. Eine wichtige Anwendung ist die Unterstützung von Dateneingabeterminals (siehe Abschnitt 3.3.2). Es gab Bedenken, dass ein Host, der nicht darauf vorbereitet war, unbekannte Telnet-Befehle korrekt zu ignorieren, abstürzen könnte, wenn er ein EOR erhielt, da EOR nicht in RFC-854 definiert worden war. Um solche Hosts zu schützen, wurde die End-of-Record-Option [TELNET:9] eingeführt; ein ordnungsgemäß implementiertes Telnet-Programm benötigt diesen Schutz jedoch nicht.
3.2.4 Telnet "Synch"-Signal: RFC-854, S. 8-10
Wenn es „dringende" TCP-Daten empfängt, muss (MUST) ein Benutzer- oder Server-Telnet alle Daten außer Telnet-Befehlen verwerfen, bis das DM (und das Ende der Dringlichkeit) erreicht ist.
Wenn es Telnet IP (Interrupt Process) sendet, sollte (SHOULD) ein Benutzer-Telnet diesem die Telnet-„Synch"-Sequenz folgen lassen, d. h. als TCP-Urgent-Daten die Sequenz „IAC IP IAC DM" senden. Der TCP-Urgent-Zeiger zeigt auf das DM-Oktett.
Wenn es einen Telnet-IP-Befehl empfängt, kann (MAY) ein Server-Telnet eine Telnet-„Synch"-Sequenz an den Benutzer zurücksenden, um den Ausgabestream zu leeren. Die Wahl sollte konsistent mit der Art und Weise sein, wie sich das Server-Betriebssystem verhält, wenn ein lokaler Benutzer einen Prozess unterbricht.
Wenn es einen Telnet-AO-Befehl empfängt, muss (MUST) ein Server-Telnet eine Telnet-„Synch"-Sequenz an den Benutzer zurücksenden, um den Ausgabestream zu leeren.
Ein Benutzer-Telnet sollte (SHOULD) die Fähigkeit haben, die Ausgabe zu leeren, wenn es ein Telnet-IP sendet; siehe auch Abschnitt 3.4.5.
DISKUSSION:
Es gibt drei mögliche Wege für ein Benutzer-Telnet, den Stream der Server-Ausgabedaten zu leeren:
(1) AO nach IP senden.
Dies veranlasst den Server-Host, ein „gepufferte-Ausgabe-leeren"-Signal an sein Betriebssystem zu senden. Das AO wird jedoch möglicherweise nicht lokal wirksam, d. h. die Terminalausgabe auf der Benutzer-Telnet-Seite wird nicht gestoppt, bis der Server-Telnet das AO empfangen und verarbeitet hat und ein „Synch" zurückgesendet hat.
(2) DO TIMING-MARK [TELNET:7] nach IP senden und alle Ausgaben lokal verwerfen, bis ein WILL/WONT TIMING-MARK vom Server-Telnet empfangen wird.
Da das DO TIMING-MARK nach dem IP am Server verarbeitet wird, sollte die Antwort darauf an der richtigen Stelle im Ausgabedatenstrom sein. Das TIMING-MARK sendet jedoch kein „gepufferte-Ausgabe-leeren"-Signal an das Server-Betriebssystem. Ob dies erforderlich ist oder nicht, hängt vom Serversystem ab.
(3) Beides tun.
Die beste Methode ist nicht ganz klar, da sie einer Reihe existierender Server-Hosts gerecht werden muss, die die Telnet-Standards auf verschiedene Weise nicht befolgen. Der sicherste Ansatz ist wahrscheinlich, eine vom Benutzer steuerbare Option bereitzustellen, um (1), (2) oder (3) auszuwählen.
3.2.5 NVT-Drucker und Tastatur: RFC-854, S. 11
Im NVT-Modus sollte (SHOULD NOT) ein Telnet keine Zeichen mit dem höchstwertigen Bit 1 senden und darf (MUST NOT) es nicht als Paritätsbit senden. Implementierungen, die das höchstwertige Bit an Anwendungen weitergeben, sollten (SHOULD) den Binärmodus aushandeln (siehe Abschnitt 3.2.6).
DISKUSSION:
Implementierer sollten sich bewusst sein, dass eine strenge Lesart von RFC-854 es einem Client oder Server, der NVT ASCII erwartet, erlaubt, Zeichen mit gesetztem höchstwertigen Bit zu ignorieren. Im Allgemeinen wird erwartet, dass der Binärmodus für die Übertragung eines erweiterten (über 7-Bit hinausgehenden) Zeichensatzes mit Telnet verwendet wird.
3.2.6 Telnet-Befehlsstruktur: RFC-854, S. 13
Da Optionen an jedem Punkt im Datenstrom erscheinen können, muss (MUST) ein Telnet-Escape-Zeichen (bekannt als IAC mit dem Wert 255), das als Daten gesendet werden soll, verdoppelt werden.
3.2.7 Telnet-Binäroption: RFC-856
Wenn die Binäroption erfolgreich ausgehandelt wurde, sind beliebige 8-Bit-Zeichen erlaubt. Der Datenstrom muss (MUST) jedoch weiterhin nach IAC-Zeichen gescannt werden, alle eingebetteten Telnet-Befehle müssen (MUST) befolgt werden, und Datenbytes, die IAC entsprechen, müssen (MUST) verdoppelt werden. Andere Zeichenverarbeitung (z. B. Ersetzen von CR durch CR NUL oder durch CR LF) darf (MUST NOT) nicht durchgeführt werden. Insbesondere gibt es im Binärmodus keine Zeilenende-Konvention (siehe Abschnitt 3.3.1).
3.2.8 Telnet Terminal-Type-Option: RFC-1091
Die Terminal-Type-Option muss (MUST) die Terminaltyp-Namen verwenden, die offiziell im RFC für zugewiesene Nummern [INTRO:5] definiert sind, wenn sie für das jeweilige Terminal verfügbar sind. Der Empfänger einer Terminal-Type-Option muss (MUST) jedoch jeden Namen akzeptieren.
3.3 SPEZIFISCHE PROBLEME
3.3.1 Telnet-Zeilenende-Konvention
Das Telnet-Protokoll definiert die Sequenz CR LF als „Zeilenende". Für Terminaleingaben entspricht dies einer Befehlsvollständigkeits- oder „Zeilenende"-Taste, die auf einem Benutzerterminal gedrückt wird; auf einem ASCII-Terminal ist dies die CR-Taste, kann aber auch als „Return" oder „Enter" bezeichnet werden.
Wenn ein Server-Telnet die Telnet-Zeilenende-Sequenz CR LF als Eingabe von einem entfernten Terminal empfängt, muss (MUST) der Effekt derselbe sein, als ob der Benutzer die „Zeilenende"-Taste auf einem lokalen Terminal gedrückt hätte. Auf Server-Hosts, die ASCII verwenden, muss insbesondere der Empfang der Telnet-Sequenz CR LF den gleichen Effekt verursachen wie ein lokaler Benutzer, der die CR-Taste auf einem lokalen Terminal drückt. Daher müssen (MUST) CR LF und CR NUL auf einem ASCII-Server-Host den gleichen Effekt haben, wenn sie als Eingabe über eine Telnet-Verbindung empfangen werden.
Ein Benutzer-Telnet muss (MUST) in der Lage sein, eine der Formen zu senden: CR LF, CR NUL und LF. Ein Benutzer-Telnet auf einem ASCII-Host sollte (SHOULD) einen vom Benutzer steuerbaren Modus haben, um entweder CR LF oder CR NUL zu senden, wenn der Benutzer die „Zeilenende"-Taste drückt, und CR LF sollte (SHOULD) der Standard sein.
3.3.2 Dateneingabeterminals
Zusätzlich zu den zeilenorientierten und zeichenorientierten ASCII-Terminals, für die Telnet entwickelt wurde, gibt es mehrere Familien von Videoanzeige-Terminals, die manchmal als „Dateneingabeterminals" oder DETs bekannt sind. Die IBM 3270-Familie ist ein bekanntes Beispiel.
3.3.3 Optionsanforderungen
Jede Telnet-Implementierung muss (MUST) die Binäroption [TELNET:3] und die Suppress Go Ahead-Option [TELNET:5] unterstützen und sollte (SHOULD) die Echo- [TELNET:4], Status- [TELNET:6], End-of-Record- [TELNET:9] und Extended Options List-Optionen [TELNET:8] unterstützen.
Ein Benutzer- oder Server-Telnet sollte (SHOULD) die Window Size-Option [TELNET:12] unterstützen, wenn das lokale Betriebssystem die entsprechende Fähigkeit bereitstellt.
3.3.4 Optionsinitiierung
Wenn das Telnet-Protokoll in einer Client/Server-Situation verwendet wird, sollte (SHOULD) der Server die Aushandlung des erwarteten Terminalinteraktionsmodus initiieren.
3.3.5 Telnet Linemode-Option
Eine wichtige neue Telnet-Option, LINEMODE [TELNET:12], wurde vorgeschlagen. Die LINEMODE-Option bietet eine Standardmethode für ein Benutzer-Telnet und ein Server-Telnet, sich darauf zu einigen, dass der Client und nicht der Server die Terminal-Zeichenverarbeitung durchführt.
3.4 TELNET/BENUTZER-SCHNITTSTELLE
3.4.1 Zeichensatz-Transparenz
Benutzer-Telnet-Implementierungen sollten (SHOULD) in der Lage sein, jedes 7-Bit-ASCII-Zeichen zu senden oder zu empfangen. Wo möglich, sollten (SHOULD) alle speziellen Zeicheninterpretationen durch das Betriebssystem des Benutzer-Hosts umgangen werden, damit diese Zeichen bequem über die Verbindung gesendet und empfangen werden können.
Ein Zeichenwert muss (MUST) als „Escape zum Befehlsmodus" reserviert werden; konventionell ermöglicht das Verdoppeln dieses Zeichens, es als Daten einzugeben. Das verwendete spezifische Zeichen sollte (SHOULD) vom Benutzer auswählbar sein.
3.4.2 Telnet-Befehle
Ein Benutzer-Telnet-Programm muss (MUST) dem Benutzer die Möglichkeit bieten, eine der Telnet-Steuerfunktionen IP, AO oder AYT einzugeben, und sollte (SHOULD) die Möglichkeit bieten, EC, EL und Break einzugeben.
3.4.3 TCP-Verbindungsfehler
Ein Benutzer-Telnet-Programm sollte (SHOULD) dem Benutzer alle TCP-Fehler melden, die von der Transportschicht gemeldet werden.
3.4.4 Nicht-Standard-Telnet-Kontaktport
Ein Benutzer-Telnet-Programm sollte (SHOULD) dem Benutzer erlauben, optional eine nicht standardmäßige Kontaktportnummer am Server-Telnet-Host anzugeben.
3.4.5 Ausgabe leeren
Ein Benutzer-Telnet-Programm sollte (SHOULD) dem Benutzer die Möglichkeit geben, anzugeben, ob die Ausgabe geleert werden soll oder nicht, wenn ein IP gesendet wird; siehe Abschnitt 3.2.4.
3.5 ZUSAMMENFASSUNG DER TELNET-ANFORDERUNGEN
| Funktionalität | Abschnitt | MUST | SHOULD | MAY | SHOULD NOT | MUST NOT |
|---|---|---|---|---|---|---|
| Optionsaushandlung | ||||||
| Optionsaushandlung implementieren | 3.2.1 | ✓ | ||||
| Aushandlungsschleifen vermeiden | 3.2.1 | ✓ | ||||
| Nicht unterstützte Optionen ablehnen | 3.2.1 | ✓ | ||||
| Aushandlung jederzeit OK | 3.2.1 | ✓ | ||||
| Standard auf NVT | 3.2.1 | ✓ | ||||
| Offiziellen Namen in Term-Type senden | 3.2.8 | ✓ | ||||
| Jeden Namen in Term-Type akzeptieren | 3.2.8 | ✓ | ||||
| Binary, Suppress-GA implementieren | 3.3.3 | ✓ | ||||
| Echo, Status, EOL, Ext-Opt-List-Optionen | 3.3.3 | ✓ | ||||
| Window-Size-Option falls geeignet | 3.3.3 | ✓ | ||||
| Server initiiert Modus-Aushandlungen | 3.3.4 | ✓ | ||||
| Steuerfunktionen | ||||||
| SE NOP DM IP AO AYT SB unterstützen | 3.2.3 | ✓ | ||||
| EOR EC EL Break unterstützen | 3.2.3 | ✓ | ||||
| Nicht unterstützte Funktionen ignorieren | 3.2.3 | ✓ | ||||
| Dringende Daten bis DM verwerfen | 3.2.4 | ✓ | ||||
| Kodierung | ||||||
| Höchstwertiges Bit im NVT nicht senden | 3.2.5 | ✓ | ||||
| Höchstwertiges Bit nicht als Parität senden | 3.2.5 | ✓ | ||||
| IAC-Byte immer verdoppeln | 3.2.6 | ✓ | ||||
| IAC im Binärmodus verdoppeln | 3.2.7 | ✓ | ||||
| Zeilenende | ||||||
| EOL am Server = lokales Zeilenende | 3.3.1 | ✓ | ||||
| ASCII-Server akzeptiert CR LF oder CR NUL | 3.3.1 | ✓ | ||||
| Benutzer kann CR LF, CR NUL, LF senden | 3.3.1 | ✓ | ||||
| ASCII-Benutzer kann CR LF/CR NUL wählen | 3.3.1 | ✓ | ||||
| Standard-Modus Benutzer ist CR LF | 3.3.1 | ✓ | ||||
| Benutzer-Telnet-Schnittstelle | ||||||
| E/A aller 7-Bit-Zeichen | 3.4.1 | ✓ | ||||
| Lokale OS-Interpretation umgehen | 3.4.1 | ✓ | ||||
| Escape-Zeichen | 3.4.1 | ✓ | ||||
| Vom Benutzer einstellbares Escape-Zeichen | 3.4.1 | ✓ | ||||
| Kann IP, AO, AYT eingeben | 3.4.2 | ✓ | ||||
| Kann EC, EL, Break eingeben | 3.4.2 | ✓ | ||||
| TCP-Fehler an Benutzer melden | 3.4.3 | ✓ | ||||
| Nicht standardmäßiger Kontaktport | 3.4.4 | ✓ | ||||
| Ausgabe-Leeren bei IP-Sendung angeben | 3.4.5 | ✓ | ||||
| Ausgabemodus manuell wiederherstellen | 3.4.5 | ✓ |