5. Compatibilité avec les anciennes versions SSH (Compatibility With Old SSH Versions)

Comme indiqué précédemment, le 'protoversion' spécifié pour ce protocole est « 2.0 ». Les versions antérieures de ce protocole n'ont pas été formellement documentées, mais il est largement connu qu'elles utilisent un 'protoversion' « 1.x » (par ex. « 1.5 » ou « 1.3 »). Au moment de la rédaction, de nombreuses implémentations de SSH utilisent la version de protocole 2.0, mais il est connu qu'il existe encore des dispositifs employant les versions précédentes. Pendant la période de transition, il est important de pouvoir fonctionner de manière compatible avec les clients et serveurs SSH déployés qui utilisent l'ancienne version du protocole. Les informations de cette section ne concernent que les implémentations prenant en charge la compatibilité avec les versions SSH 1.x. Pour les personnes intéressées, la seule documentation connue du protocole 1.x se trouve dans des fichiers README livrés avec le code source [ssh-1.2.30].

5.1. Ancien client, nouveau serveur (Old Client, New Server)

Les implémentations serveur PEUVENT (MAY) prendre en charge un indicateur de compatibilité configurable qui active la compatibilité avec les anciennes versions. Lorsque cet indicateur est activé, le serveur DEVRAIT (SHOULD) identifier son 'protoversion' comme « 1.99 ». Les clients utilisant le protocole 2.0 DOIVENT (MUST) pouvoir considérer cela comme identique à « 2.0 ». Dans ce mode, le serveur NE DEVRAIT PAS (SHOULD NOT) envoyer le caractère retour chariot (ASCII 13) après la chaîne d'identification.

En mode compatibilité, le serveur NE DEVRAIT PAS (SHOULD NOT) envoyer d'autres données après sa chaîne d'identification tant qu'il n'a pas reçu une chaîne d'identification du client. Le serveur peut alors déterminer si le client utilise un ancien protocole et peut revenir à l'ancien protocole si nécessaire. En mode compatibilité, le serveur NE DOIT PAS (MUST NOT) envoyer de données supplémentaires avant la chaîne d'identification.

Lorsque la compatibilité avec les anciens clients n'est pas nécessaire, le serveur PEUT (MAY) envoyer ses données initiales d'échange de clés immédiatement après la chaîne d'identification.

5.2. Nouveau client, ancien serveur (New Client, Old Server)

Comme le nouveau client PEUT (MAY) immédiatement envoyer des données supplémentaires après sa chaîne d'identification (avant de recevoir la chaîne d'identification du serveur), l'ancien protocole peut déjà être corrompu lorsque le client apprend que le serveur est ancien. Lorsque cela se produit, le client DEVRAIT (SHOULD) fermer la connexion au serveur et se reconnecter en utilisant l'ancien protocole.

5.3. Taille de paquet et surcoût (Packet Size and Overhead)

Certains lecteurs s'inquiéteront de l'augmentation de la taille des paquets due aux nouveaux en-têtes, au bourrage (padding) et au code d'authentification des messages (Message Authentication Code, MAC). La taille minimale d'un paquet est de l'ordre de 28 octets (selon les algorithmes négociés). L'augmentation est négligeable pour les gros paquets, mais très significative pour les paquets d'un octet (sessions de type telnet). Il existe toutefois plusieurs facteurs qui font qu'il ne s'agit pratiquement jamais d'un problème réel :

La taille minimale d'un en-tête TCP/IP est de 32 octets. Ainsi, l'augmentation est en réalité d'environ 33 à 51 octets.
La taille minimale du champ de données d'un paquet Ethernet est de 46 octets [RFC0894]. Ainsi, l'augmentation est d'au plus 5 octets. Si l'on tient compte des en-têtes Ethernet, l'augmentation est inférieure à 10 pour cent.
La fraction totale des données de type telnet sur Internet est négligeable, même avec des tailles de paquet accrues.

Le seul environnement où l'augmentation de la taille des paquets est susceptible d'avoir un effet significatif est PPP [RFC1661] sur des lignes modem lentes (PPP compresse les en-têtes TCP/IP, ce qui met en relief l'augmentation de la taille des paquets). Cependant, avec les modems modernes, le temps nécessaire au transfert est de l'ordre de 2 millisecondes, ce qui est nettement plus rapide que la frappe humaine.

Il existe aussi des questions liées à la taille maximale des paquets. Pour minimiser les retards dans les mises à jour d'écran, on ne souhaite pas de paquets excessifs pour les sessions interactives. La taille maximale des paquets est négociée séparément pour chaque canal.