5. Compatibility With Old SSH Versions (Compatibilità con vecchie versioni SSH)

Come già indicato, la 'protoversion' specificata per questo protocollo è "2.0". Le versioni precedenti di questo protocollo non sono state formalmente documentate, ma è ampiamente noto che usano 'protoversion' "1.x" (ad esempio, "1.5" o "1.3"). Al momento della stesura di questo documento, molte implementazioni di SSH utilizzano la versione di protocollo 2.0, ma è noto che esistono ancora dispositivi che usano le versioni precedenti. Durante il periodo di transizione, è importante poter operare in modo compatibile con i client e server SSH installati che usano la versione più vecchia del protocollo. Le informazioni in questa sezione sono rilevanti solo per le implementazioni che supportano la compatibilità con le versioni SSH 1.x. Per chi fosse interessato, l'unica documentazione nota del protocollo 1.x è contenuta in file README forniti con il codice sorgente [ssh-1.2.30].

5.1. Old Client, New Server (Client vecchio, server nuovo)

Le implementazioni del server POSSONO supportare un flag di compatibilità configurabile che abilita la compatibilità con le versioni vecchie. Quando questo flag è attivo, il server DOVREBBE identificare la sua 'protoversion' come "1.99". I client che usano il protocollo 2.0 DEVONO essere in grado di identificare questo come identico a "2.0". In questa modalità, il server NON DOVREBBE inviare il carattere Carriage Return (ASCII 13) dopo la stringa di identificazione.

In modalità di compatibilità, il server NON DOVREBBE inviare ulteriori dati dopo aver inviato la sua stringa di identificazione finché non ha ricevuto una stringa di identificazione dal client. Il server può quindi determinare se il client usa un protocollo vecchio e può tornare al vecchio protocollo se necessario. In modalità di compatibilità, il server NON DEVE inviare dati aggiuntivi prima della stringa di identificazione.

Quando la compatibilità con i client vecchi non è necessaria, il server PUÒ inviare immediatamente i suoi dati iniziali di scambio di chiavi dopo la stringa di identificazione.

5.2. New Client, Old Server (Client nuovo, server vecchio)

Poiché il nuovo client PUÒ inviare immediatamente dati aggiuntivi dopo la sua stringa di identificazione (prima di ricevere la stringa di identificazione del server), il vecchio protocollo può essere già corrotto quando il client apprende che il server è vecchio. Quando ciò accade, il client DOVREBBE chiudere la connessione al server e riconnettersi usando il vecchio protocollo.

5.3. Packet Size and Overhead (Dimensione dei pacchetti e overhead)

Alcuni lettori si preoccuperanno dell'aumento della dimensione del pacchetto dovuto a nuove intestazioni, padding e Message Authentication Code (MAC, codice di autenticazione del messaggio). La dimensione minima del pacchetto è dell'ordine di 28 byte (a seconda degli algoritmi negoziati). L'aumento è trascurabile per i pacchetti grandi, ma molto significativo per pacchetti di un byte (sessioni tipo telnet). Esistono tuttavia diversi fattori che rendono questa questione irrilevante nella quasi totalità dei casi:

La dimensione minima di un'intestazione TCP/IP è 32 byte. Quindi, l'aumento è in realtà da 33 a 51 byte (approssimativamente).
La dimensione minima del campo dati di un pacchetto Ethernet è 46 byte [RFC0894]. Quindi, l'aumento non è superiore a 5 byte. Se si considerano le intestazioni Ethernet, l'aumento è inferiore al 10 percento.
La frazione totale di dati tipo telnet in Internet è trascurabile, anche con dimensioni di pacchetto aumentate.

L'unico ambiente in cui l'aumento della dimensione del pacchetto ha probabilmente un effetto significativo è PPP [RFC1661] su linee modem lente (PPP comprime le intestazioni TCP/IP, enfatizzando l'aumento della dimensione del pacchetto). Tuttavia, con i modem moderni, il tempo necessario al trasferimento è dell'ordine di 2 millisecondi, molto più veloce di quanto le persone possano digitare.

Vi sono anche questioni relative alla dimensione massima del pacchetto. Per ridurre al minimo i ritardi negli aggiornamenti dello schermo, non si desiderano pacchetti eccessivamente grandi per sessioni interattive. La dimensione massima del pacchetto è negoziata separatamente per ogni canale (channel).