4. Mise en place de la connexion (Connection Setup)

SSH fonctionne sur tout transport 8 bits propre (8-bit clean) et transparent au binaire (binary-transparent). Le transport sous-jacent DEVRAIT (SHOULD) se prémunir contre les erreurs de transmission, car de telles erreurs provoquent la fermeture de la connexion SSH.

Le client initie la connexion.

4.1. Utilisation sur TCP/IP (Use over TCP/IP)

Lorsqu'il est utilisé sur TCP/IP, le serveur écoute normalement les connexions sur le port 22. Ce numéro de port a été enregistré auprès de l'IANA et a été officiellement attribué à SSH.

4.2. Échange de version de protocole (Protocol Version Exchange)

Lorsque la connexion a été établie, les deux parties DOIVENT (MUST) envoyer une chaîne d'identification (identification string). Cette chaîne d'identification DOIT (MUST) être

SSH-protoversion-softwareversion SP comments CR LF

Comme le protocole défini dans cet ensemble de documents est la version 2.0, le champ 'protoversion' DOIT (MUST) être « 2.0 ». La chaîne 'comments' est OPTIONNELLE (OPTIONAL). Si la chaîne 'comments' est incluse, un caractère « espace » (indiqué ci-dessus par SP, ASCII 32) DOIT (MUST) séparer les chaînes 'softwareversion' et 'comments'. L'identification DOIT (MUST) se terminer par un unique retour chariot (Carriage Return, CR) et un unique saut de ligne (Line Feed, LF) (ASCII 13 et 10, respectivement). Les implémentateurs qui souhaitent conserver la compatibilité avec d'anciennes versions non documentées de ce protocole peuvent traiter la chaîne d'identification sans exiger la présence du retour chariot, pour les raisons exposées à la section 5 du présent document. Le caractère nul NE DOIT PAS (MUST NOT) être envoyé. La longueur maximale de la chaîne est de 255 caractères, y compris le retour chariot et le saut de ligne.

La partie de la chaîne d'identification qui précède le retour chariot et le saut de ligne est utilisée dans l'échange de clés Diffie-Hellman (voir section 8).

Le serveur PEUT (MAY) envoyer d'autres lignes de données avant d'envoyer la chaîne de version. Chaque ligne DEVRAIT (SHOULD) se terminer par un retour chariot et un saut de ligne. De telles lignes NE DOIVENT PAS (MUST NOT) commencer par « SSH- », et DEVRAIENT (SHOULD) être encodées en UTF-8 ISO-10646 [RFC3629] (la langue n'est pas spécifiée). Les clients DOIVENT (MUST) être capables de traiter de telles lignes. De telles lignes PEUVENT (MAY) être ignorées silencieusement, ou PEUVENT (MAY) être affichées à l'utilisateur du client. Si elles sont affichées, un filtrage des caractères de contrôle, comme discuté dans [SSH-ARCH], DEVRAIT (SHOULD) être utilisé. L'usage principal de cette fonctionnalité est de permettre aux TCP-wrappers d'afficher un message d'erreur avant de déconnecter.

Les chaînes 'protoversion' et 'softwareversion' DOIVENT (MUST) être composées de caractères US-ASCII imprimables, à l'exception des caractères d'espace blanc (whitespace) et du signe moins (-). La chaîne 'softwareversion' sert principalement à déclencher des extensions de compatibilité et à indiquer les capacités d'une implémentation. La chaîne 'comments' DEVRAIT (SHOULD) contenir des informations supplémentaires pouvant être utiles pour résoudre les problèmes des utilisateurs. Ainsi, un exemple de chaîne d'identification valide est

SSH-2.0-billsSSH_3.6.3q3<CR><LF>

Cette chaîne d'identification ne contient pas la chaîne optionnelle 'comments' et se termine donc immédiatement après 'softwareversion' par un CR et un LF.

L'échange de clés commencera immédiatement après l'envoi de cet identifiant. Tous les paquets suivant la chaîne d'identification DOIVENT (SHALL) utiliser le protocole de paquets binaires (binary packet protocol), décrit à la section 6.