Pourquoi la commande ssh ne suit-elle pas RFC sur l'URI?

Le RFC:

• Schéma URI (Uniform Resource Identifier) ​​pour le protocole SFTP (Secure File Transfer Protocol) et SSH (Secure Shell)

présente l'URI SSH comme:

ssh://[<user>[;fingerprint=<host-key fingerprint>]@]<host>[:<port>]

Existe-t-il des raisons connues pour lesquelles la commande OpenSSH ssh ne respecte pas cette norme avec l'option hostname? Il n'accepte pas de port après deux points.

Exemple d'URI que je m'attendais à travailler:

$ ssh user@host:2222
ssh: Could not resolve hostname host:2222: Name or service not known

sshest antérieure au format URI plus général ( 1998 ) de plusieurs années (1995 IIRC).

J'ai initialement posté cela en tant que commentaire, mais je le développerai un peu en tant que réponse.

OpenSSH contient plusieurs utilitaires, parmi lesquels les plus notables sont sshet scp. Bien que sshne se connecte qu'à un ordinateur distant (et exécute éventuellement une commande sur cet ordinateur distant), d'autres parties d'OpenSSH telles que la scpsyntaxe sont légèrement différentes. Du fait qu'ils font tous partie de la suite OpenSSH, ceux-ci partagent probablement beaucoup de code.

Avec scp, vous spécifiez un fichier distant sur une forme de triplet comme user@host:remotefilename, où remotefilenamepeut être un chemin relatif ou absolu.

Si la partie hôte était autorisée à figurer sur le formulairehost:port , cela créerait une ambiguïté potentielle: fait [email protected]:2222référence à ~jdoe/2222sur host.example.com lors de la connexion sur le port standard, ou ne fait-elle référence à aucun fichier (ou pire, ~jdoe) sur host.example.com lors de la connexion via le port 2222?

La syntaxe URI que vous présentez est plus limitée dans ce qu'elle peut exprimer (elle ne permet pas une spécification de nom de fichier), et plus important encore, il ne peut jamais y avoir d'ambiguïté sauf si le nom d'hôte réel inclut un :(ce que je ne pense pas est même possible dans DNS, et ce n'est certainement pas courant, alors que les noms de fichiers entièrement numériques ne sont pas si inhabituels).

Lorsque SSH a été développé à l'origine , il a été développé comme un remplacement plus sûr et intégré à la suite d'outils RSH / rlogin antérieure. Je ne sais pas quelle était la syntaxe de ligne de commande au début des années 1990 (le RFC décrivant rlogin est le RFC 1282 de décembre 1991 , antérieur au document que vous citez d'environ 15 ans), mais cela ne semble pas déraisonnable suppose qu'il utilise une syntaxe très similaire car le nom d'utilisateur a été transmis spécialement dans le protocole rlogin. Citant RFC 1282:

Une fois la connexion établie, le client envoie quatre chaînes à terminaison nulle au serveur. La première est une chaîne vide (c'est-à-dire qu'elle se compose uniquement d'un seul octet zéro), suivie de trois chaînes non nulles: le nom d'utilisateur du client, le nom d' utilisateur du serveur et le type et la vitesse du terminal. Plus explicitement: ...

Le nom d'utilisateur local peut être obtenu via diverses installations du système, mais le nom d'utilisateur distant doit être spécifié de manière explicite . En plus d' @être souvent prononcé "à" et donc d'être un choix assez naturel pour commencer, user@hostcorrespond bien à la syntaxe établie pour, par exemple, la transmission d'e-mails (comparer une adresse SMTP de user@host, où hostpeut être un hôte réel ou un nom DNS avec un enregistrement MX pointant à un hôte réel), donc c'était probablement un choix facile plutôt que de créer quelque chose de nouveau.

Il convient également de noter ce que Stéphane Chazelas a souligné dans un commentaire : le document auquel vous faites référence n'est pas un RFC, c'est un brouillon actuel de sept ans qui, à en juger par une recherche rapide sur Google, ne semble jamais avoir décollé. . Cela arrive tout le temps; quelque chose est proposé, mais ne recueille pas le support pour en faire un RFC (et même beaucoup, beaucoup de RFC ne sont pas standards).