¿Por qué el comando ssh no sigue RFC en URI?

El RFC:

• Esquema de identificador uniforme de recursos (URI) para el Protocolo seguro de transferencia de archivos (SFTP) y Secure Shell (SSH)

presenta el SSH URI como:

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

¿Hay alguna razón conocida por la cual el comando OpenSSH ssh no sigue este estándar con la opción de nombre de host? No acepta un puerto después de dos puntos.

Ejemplo de un URI que esperaba trabajar:

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

sshes anterior al formato URI más general ( 1998 ) por varios años (1995 IIRC).

Originalmente publiqué esto como un comentario, pero lo desarrollaré un poco como respuesta.

OpenSSH contiene varias utilidades, entre las cuales las más notables son sshy scp. Si bien sshsolo se conectará a una computadora remota (y posiblemente ejecutará un comando en esa computadora remota), otras partes de OpenSSH como scptienen una sintaxis ligeramente diferente. En virtud de que todos forman parte de la suite OpenSSH, es probable que estos compartan mucho código.

Con scp, puede especificar un archivo remoto en un formulario de triplete como user@host:remotefilename, donde remotefilenamepuede ser una ruta relativa o absoluta.

Si se permitiera que la parte del host estuviera en el formulariohost:port , esto crearía una posible ambigüedad: se [email protected]:2222refiere a ~jdoe/2222host.example.com cuando se conecta en el puerto estándar, o no se refiere a ningún archivo (o peor ~jdoe) en host.example.com cuando se conecta a través del puerto 2222?

La sintaxis de URI que presenta es más limitada en lo que puede expresar (no permite una especificación de nombre de archivo), y lo que es más importante, nunca puede haber ambigüedad a menos que el nombre de host real incluya un :(que no creo incluso es posible en DNS, y ciertamente no se hace comúnmente, mientras que los nombres de archivos totalmente numéricos no son tan inusuales).

Cuando SSH se desarrolló originalmente , se desarrolló como un reemplazo directo más seguro para el conjunto de herramientas RSH / rlogin anterior. No sé cuál fue la sintaxis de la línea de comandos para eso a principios de la década de 1990 (el RFC que describe rlogin es RFC 1282 de diciembre de 1991 , anterior al documento que cita en unos 15 años), pero no parece irrazonable Supongo que utilizó una sintaxis muy similar porque el nombre de usuario se transmitió especialmente en el protocolo rlogin. Citando RFC 1282:

Al establecer la conexión, el cliente envía cuatro cadenas terminadas en nulo al servidor. La primera es una cadena vacía (es decir, consta únicamente de un solo byte cero), seguida de tres cadenas no nulas: el nombre de usuario del cliente, el nombre de usuario del servidor y el tipo y la velocidad del terminal. Más explícitamente: ...

El nombre de usuario local se puede obtener a través de varias instalaciones del sistema, pero el nombre de usuario remoto debe especificarse explícitamente de alguna manera . Además de que a @menudo se pronuncia "at" y, por lo tanto, es una opción bastante natural para empezar, se user@hostasigna bien a la sintaxis establecida, por ejemplo, para la transmisión de correo electrónico (compare una dirección SMTP de user@host, donde hostpuede ser un host real o un nombre DNS con un registro MX apuntando) para un host real), por lo que probablemente fue una elección fácil en lugar de inventar algo nuevo.

También vale la pena señalar lo que Stephane Chazelas señaló en un comentario : el documento al que hace referencia no es un RFC, es actualmente un borrador de siete años que, a juzgar por una rápida búsqueda en Google para confirmar, parece que nunca se ha despegado . Eso pasa todo el tiempo; se propone algo, pero no obtiene el apoyo para convertirlo en un RFC (e incluso muchos, muchos RFC no son estándares).