3. Remote Login - Protocole TELNET
3.1 INTRODUCTION
Telnet est le protocole d'application Internet standard pour la connexion à distance. Il fournit les règles d'encodage pour relier le clavier/affichage d'un utilisateur sur un système client (« utilisateur ») avec un interpréteur de commandes sur un système serveur distant. Un sous-ensemble du protocole Telnet est également incorporé dans d'autres protocoles d'application, par exemple FTP et SMTP.
Telnet utilise une seule connexion TCP, et son flux de données normal (mode « terminal virtuel réseau » ou « NVT ») est ASCII 7 bits avec des séquences d'échappement pour intégrer les fonctions de contrôle. Telnet permet également la négociation de nombreux modes et fonctions optionnels.
La spécification Telnet primaire se trouve dans RFC-854 [TELNET:1], tandis que les options sont définies dans de nombreux autres RFC ; voir Section 7 pour les références.
3.2 PARCOURS DU PROTOCOLE
3.2.1 Négociation d'options : RFC-854, pp. 2-3
Chaque implémentation Telnet doit (MUST) inclure la mécanique de négociation et de sous-négociation d'options [TELNET:2].
Un hôte doit (MUST) suivre attentivement les règles de RFC-854 pour éviter les boucles de négociation d'options. Un hôte doit (MUST) refuser (c'est-à-dire répondre WONT/DONT à un DO/WILL) une option non supportée. La négociation d'options devrait (SHOULD) continuer à fonctionner (même si toutes les demandes sont refusées) pendant toute la durée de vie d'une connexion Telnet.
Si toutes les négociations d'options échouent, une implémentation Telnet doit (MUST) par défaut être et supporter un NVT.
DISCUSSION :
Même si des « terminaux » plus sophistiqués et la prise en charge des négociations d'options deviennent la norme, toutes les implémentations doivent être préparées à supporter un NVT pour toute communication utilisateur-serveur.
3.2.2 Fonction Go-Ahead de Telnet : RFC-854, p. 5, et RFC-858
Sur un hôte qui n'envoie jamais la commande Telnet Go Ahead (GA), le serveur Telnet doit (MUST) tenter de négocier l'option Suppress Go Ahead (c'est-à-dire envoyer « WILL Suppress Go Ahead »). Un Telnet utilisateur ou serveur doit (MUST) toujours accepter la négociation de l'option Suppress Go Ahead.
Lorsqu'il pilote un terminal full-duplex pour lequel GA n'a aucune signification, une implémentation Telnet utilisateur peut (MAY) ignorer les commandes GA.
DISCUSSION :
Les terminaux half-duplex (« clavier verrouillé ») ligne par ligne pour lesquels le mécanisme Go-Ahead a été conçu ont largement disparu de la scène. Il s'est avéré difficile d'implémenter l'envoi du signal Go-Ahead dans de nombreux systèmes d'exploitation, même certains systèmes qui supportent des terminaux half-duplex natifs. La difficulté est généralement que le code du serveur Telnet n'a pas accès aux informations indiquant si le processus utilisateur est bloqué en attente d'entrée depuis la connexion Telnet, c'est-à-dire qu'il ne peut pas déterminer de manière fiable quand envoyer une commande GA. Par conséquent, la plupart des hôtes serveurs Telnet n'envoient pas de commandes GA.
L'effet des règles de cette section est de permettre à l'une ou l'autre extrémité d'une connexion Telnet de mettre son veto à l'utilisation des commandes GA.
Il existe une classe de terminaux half-duplex qui est encore commercialement importante : les « terminaux de saisie de données », qui interagissent de manière plein écran. Cependant, le support des terminaux de saisie de données utilisant le protocole Telnet ne nécessite pas le signal Go Ahead ; voir Section 3.3.2.
3.2.3 Fonctions de contrôle : RFC-854, pp. 7-8
La liste des commandes Telnet a été étendue pour inclure EOR (End-of-Record), avec le code 239 [TELNET:9].
Les Telnets utilisateur et serveur peuvent (MAY) supporter les fonctions de contrôle EOR, EC, EL et Break, et doivent (MUST) supporter AO, AYT, DM, IP, NOP, SB et SE.
Un hôte doit (MUST) être capable de recevoir et d'ignorer toute fonction de contrôle Telnet qu'il ne supporte pas.
DISCUSSION :
Notez qu'un serveur Telnet est requis pour supporter la fonction Telnet IP (Interrupt Process), même si l'hôte serveur dispose d'une fonction équivalente dans le flux (par exemple, Control-C dans de nombreux systèmes). La fonction Telnet IP peut être plus forte qu'une commande d'interruption dans le flux, en raison de l'effet hors bande des données urgentes TCP.
La fonction de contrôle EOR peut être utilisée pour délimiter le flux. Une application importante est le support des terminaux de saisie de données (voir Section 3.3.2). Il y avait une préoccupation que puisque EOR n'avait pas été défini dans RFC-854, un hôte qui n'était pas préparé à ignorer correctement les commandes Telnet inconnues pourrait planter s'il recevait un EOR. Pour protéger de tels hôtes, l'option End-of-Record [TELNET:9] a été introduite ; cependant, un programme Telnet correctement implémenté n'aura pas besoin de cette protection.
3.2.4 Signal "Synch" de Telnet : RFC-854, pp. 8-10
Lorsqu'il reçoit des données TCP « urgentes », un Telnet utilisateur ou serveur doit (MUST) jeter toutes les données sauf les commandes Telnet jusqu'à ce que le DM (et la fin de l'urgent) soit atteint.
Lorsqu'il envoie Telnet IP (Interrupt Process), un Telnet utilisateur devrait (SHOULD) le suivre par la séquence « Synch » de Telnet, c'est-à-dire envoyer comme données TCP urgentes la séquence « IAC IP IAC DM ». Le pointeur urgent TCP pointe vers l'octet DM.
Lorsqu'il reçoit une commande Telnet IP, un serveur Telnet peut (MAY) renvoyer une séquence « Synch » de Telnet à l'utilisateur, pour vider le flux de sortie. Le choix devrait être cohérent avec la façon dont le système d'exploitation serveur se comporte lorsqu'un utilisateur local interrompt un processus.
Lorsqu'il reçoit une commande Telnet AO, un serveur Telnet doit (MUST) renvoyer une séquence « Synch » de Telnet à l'utilisateur, pour vider le flux de sortie.
Un Telnet utilisateur devrait (SHOULD) avoir la capacité de vider la sortie lorsqu'il envoie un Telnet IP ; voir aussi Section 3.4.5.
DISCUSSION :
Il existe trois façons possibles pour un Telnet utilisateur de vider le flux de données de sortie du serveur :
(1) Envoyer AO après IP.
Cela amènera l'hôte serveur à envoyer un signal « vider la sortie tamponnée » à son système d'exploitation. Cependant, l'AO peut ne pas prendre effet localement, c'est-à-dire arrêter la sortie du terminal côté Telnet utilisateur, jusqu'à ce que le serveur Telnet ait reçu et traité l'AO et ait renvoyé un « Synch ».
(2) Envoyer DO TIMING-MARK [TELNET:7] après IP, et jeter toute la sortie localement jusqu'à ce qu'un WILL/WONT TIMING-MARK soit reçu du serveur Telnet.
Puisque le DO TIMING-MARK sera traité après l'IP au serveur, la réponse devrait être au bon endroit dans le flux de données de sortie. Cependant, le TIMING-MARK n'enverra pas de signal « vider la sortie tamponnée » au système d'exploitation du serveur. Que cela soit nécessaire ou non dépend du système serveur.
(3) Faire les deux.
La meilleure méthode n'est pas entièrement claire, car elle doit accommoder un certain nombre d'hôtes serveurs existants qui ne suivent pas les standards Telnet de diverses manières. L'approche la plus sûre est probablement de fournir une option contrôlable par l'utilisateur pour sélectionner (1), (2) ou (3).
3.2.5 Imprimante et clavier NVT : RFC-854, p. 11
En mode NVT, un Telnet ne devrait pas (SHOULD NOT) envoyer de caractères avec le bit de poids fort à 1, et ne doit pas (MUST NOT) l'envoyer comme bit de parité. Les implémentations qui passent le bit de poids fort aux applications devraient (SHOULD) négocier le mode binaire (voir Section 3.2.6).
DISCUSSION :
Les implémenteurs doivent être conscients qu'une lecture stricte de RFC-854 permet à un client ou serveur attendant NVT ASCII d'ignorer les caractères avec le bit de poids fort défini. En général, le mode binaire est censé être utilisé pour la transmission d'un jeu de caractères étendu (au-delà de 7 bits) avec Telnet.
3.2.6 Structure des commandes Telnet : RFC-854, p. 13
Puisque les options peuvent apparaître à n'importe quel point dans le flux de données, un caractère d'échappement Telnet (connu sous le nom d'IAC, avec la valeur 255) à envoyer comme données doit (MUST) être doublé.
3.2.7 Option binaire Telnet : RFC-856
Lorsque l'option binaire a été négociée avec succès, des caractères 8 bits arbitraires sont autorisés. Cependant, le flux de données doit (MUST) toujours être scanné pour les caractères IAC, toutes les commandes Telnet intégrées doivent (MUST) être obéies, et les octets de données égaux à IAC doivent (MUST) être doublés. Aucun autre traitement de caractères (par exemple, remplacer CR par CR NUL ou par CR LF) ne doit (MUST NOT) être effectué. En particulier, il n'y a pas de convention de fin de ligne (voir Section 3.3.1) en mode binaire.
3.2.8 Option Terminal-Type de Telnet : RFC-1091
L'option Terminal-Type doit (MUST) utiliser les noms de types de terminaux officiellement définis dans le RFC des numéros attribués [INTRO:5], lorsqu'ils sont disponibles pour le terminal particulier. Cependant, le récepteur d'une option Terminal-Type doit (MUST) accepter n'importe quel nom.
3.3 PROBLÈMES SPÉCIFIQUES
3.3.1 Convention de fin de ligne Telnet
Le protocole Telnet définit la séquence CR LF pour signifier « fin de ligne ». Pour l'entrée du terminal, cela correspond à une touche de complétion de commande ou « fin de ligne » pressée sur un terminal utilisateur ; sur un terminal ASCII, c'est la touche CR, mais elle peut également être étiquetée « Return » ou « Enter ».
Lorsqu'un serveur Telnet reçoit la séquence de fin de ligne Telnet CR LF comme entrée depuis un terminal distant, l'effet doit (MUST) être le même que si l'utilisateur avait pressé la touche « fin de ligne » sur un terminal local. Sur les hôtes serveurs qui utilisent ASCII, en particulier, la réception de la séquence Telnet CR LF doit causer le même effet qu'un utilisateur local pressant la touche CR sur un terminal local. Ainsi, CR LF et CR NUL doivent (MUST) avoir le même effet sur un hôte serveur ASCII lorsqu'ils sont reçus comme entrée sur une connexion Telnet.
Un Telnet utilisateur doit (MUST) être capable d'envoyer l'une des formes : CR LF, CR NUL et LF. Un Telnet utilisateur sur un hôte ASCII devrait (SHOULD) avoir un mode contrôlable par l'utilisateur pour envoyer soit CR LF soit CR NUL lorsque l'utilisateur presse la touche « fin de ligne », et CR LF devrait (SHOULD) être le défaut.
3.3.2 Terminaux de saisie de données
En plus des terminaux ASCII orientés ligne et orientés caractère pour lesquels Telnet a été conçu, il existe plusieurs familles de terminaux d'affichage vidéo parfois appelés « terminaux de saisie de données » ou DET. La famille IBM 3270 en est un exemple bien connu.
3.3.3 Exigences d'options
Chaque implémentation Telnet doit (MUST) supporter l'option binaire [TELNET:3] et l'option Suppress Go Ahead [TELNET:5], et devrait (SHOULD) supporter les options Echo [TELNET:4], Status [TELNET:6], End-of-Record [TELNET:9] et Extended Options List [TELNET:8].
Un Telnet utilisateur ou serveur devrait (SHOULD) supporter l'option Window Size [TELNET:12] si le système d'exploitation local fournit la capacité correspondante.
3.3.4 Initiation des options
Lorsque le protocole Telnet est utilisé dans une situation client/serveur, le serveur devrait (SHOULD) initier la négociation du mode d'interaction terminal qu'il attend.
3.3.5 Option Linemode de Telnet
Une nouvelle option Telnet importante, LINEMODE [TELNET:12], a été proposée. L'option LINEMODE fournit une méthode standard pour qu'un Telnet utilisateur et un serveur Telnet conviennent que le client plutôt que le serveur effectuera le traitement des caractères du terminal.
3.4 INTERFACE TELNET/UTILISATEUR
3.4.1 Transparence du jeu de caractères
Les implémentations Telnet utilisateur devraient (SHOULD) être capables d'envoyer ou de recevoir n'importe quel caractère ASCII 7 bits. Lorsque possible, toute interprétation de caractères spéciaux par le système d'exploitation de l'hôte utilisateur devrait (SHOULD) être contournée afin que ces caractères puissent être commodément envoyés et reçus sur la connexion.
Une certaine valeur de caractère doit (MUST) être réservée comme « échappement vers le mode commande » ; conventionnellement, doubler ce caractère permet de le saisir comme données. Le caractère spécifique utilisé devrait (SHOULD) être sélectionnable par l'utilisateur.
3.4.2 Commandes Telnet
Un programme Telnet utilisateur doit (MUST) fournir à l'utilisateur la capacité d'entrer l'une des fonctions de contrôle Telnet IP, AO ou AYT, et devrait (SHOULD) fournir la capacité d'entrer EC, EL et Break.
3.4.3 Erreurs de connexion TCP
Un programme Telnet utilisateur devrait (SHOULD) signaler à l'utilisateur toute erreur TCP signalée par la couche transport.
3.4.4 Port de contact Telnet non par défaut
Un programme Telnet utilisateur devrait (SHOULD) permettre à l'utilisateur de spécifier optionnellement un numéro de port de contact non standard sur l'hôte serveur Telnet.
3.4.5 Vidage de la sortie
Un programme Telnet utilisateur devrait (SHOULD) fournir à l'utilisateur la capacité de spécifier si la sortie doit être vidée ou non lorsqu'un IP est envoyé ; voir Section 3.2.4.
3.5 RÉSUMÉ DES EXIGENCES TELNET
| Fonctionnalité | Section | MUST | SHOULD | MAY | SHOULD NOT | MUST NOT |
|---|---|---|---|---|---|---|
| Négociation d'options | ||||||
| Implémenter la négociation d'options | 3.2.1 | ✓ | ||||
| Éviter les boucles de négociation | 3.2.1 | ✓ | ||||
| Refuser les options non supportées | 3.2.1 | ✓ | ||||
| Négociation OK à tout moment | 3.2.1 | ✓ | ||||
| Par défaut sur NVT | 3.2.1 | ✓ | ||||
| Envoyer nom officiel dans Term-Type | 3.2.8 | ✓ | ||||
| Accepter tout nom dans Term-Type | 3.2.8 | ✓ | ||||
| Implémenter Binary, Suppress-GA | 3.3.3 | ✓ | ||||
| Options Echo, Status, EOL, Ext-Opt-List | 3.3.3 | ✓ | ||||
| Option Window-Size si approprié | 3.3.3 | ✓ | ||||
| Serveur initie négociations de mode | 3.3.4 | ✓ | ||||
| Fonctions de contrôle | ||||||
| Supporter SE NOP DM IP AO AYT SB | 3.2.3 | ✓ | ||||
| Supporter EOR EC EL Break | 3.2.3 | ✓ | ||||
| Ignorer fonctions non supportées | 3.2.3 | ✓ | ||||
| Jeter données urgentes jusqu'à DM | 3.2.4 | ✓ | ||||
| Encodage | ||||||
| Ne pas envoyer bit haut en NVT | 3.2.5 | ✓ | ||||
| Ne pas envoyer bit haut comme parité | 3.2.5 | ✓ | ||||
| Toujours doubler octet IAC | 3.2.6 | ✓ | ||||
| Doubler IAC en mode binaire | 3.2.7 | ✓ | ||||
| Fin de ligne | ||||||
| EOL serveur = fin de ligne locale | 3.3.1 | ✓ | ||||
| Serveur ASCII accepte CR LF ou CR NUL | 3.3.1 | ✓ | ||||
| Utilisateur peut envoyer CR LF, CR NUL, LF | 3.3.1 | ✓ | ||||
| Utilisateur ASCII peut sélectionner CR LF/CR NUL | 3.3.1 | ✓ | ||||
| Mode par défaut utilisateur est CR LF | 3.3.1 | ✓ | ||||
| Interface utilisateur Telnet | ||||||
| E/S de tous les caractères 7 bits | 3.4.1 | ✓ | ||||
| Contourner interprétation OS locale | 3.4.1 | ✓ | ||||
| Caractère d'échappement | 3.4.1 | ✓ | ||||
| Caractère d'échappement paramétrable | 3.4.1 | ✓ | ||||
| Peut entrer IP, AO, AYT | 3.4.2 | ✓ | ||||
| Peut entrer EC, EL, Break | 3.4.2 | ✓ | ||||
| Signaler erreurs TCP à l'utilisateur | 3.4.3 | ✓ | ||||
| Port de contact non par défaut | 3.4.4 | ✓ | ||||
| Spécifier vidage sortie lors envoi IP | 3.4.5 | ✓ | ||||
| Restaurer manuellement mode sortie | 3.4.5 | ✓ |