为什么 ssh 命令不遵循 URI 上的 RFC？

Question

RFC：

• 用于安全文件传输协议 (SFTP) 和安全外壳 (SSH) 的统一资源标识符 (URI) 方案

将 SSH URI 表示为：

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

OpenSSH ssh 命令不遵循此标准的主机名选项是否有任何已知原因？它不接受冒号后的端口。

我期望工作的 URI 示例：

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

Answer 1

我最初将此作为评论发布，但将其充实一点作为答案。

OpenSSH 包含几个实用程序，其中最著名的是ssh和scp。虽然ssh只会连接到远程计算机（并可能在该远程计算机上执行命令），但 OpenSSH 的其他部分（例如）的scp语法略有不同。由于它们都是 OpenSSH 套件的一部分，因此它们可能共享大量代码。

使用scp，您可以将三元组形式的远程文件指定为user@host:remotefilename，其中remotefilename可以是相对或绝对路径。

如果主机部分被允许在表单上host:port，这将产生潜在的歧义：在标准端口上连接时是否jdoe@host.example.com:2222引用~jdoe/2222host.example.com 上的文件，或者它根本不引用任何文件（或更糟的是，~jdoe） host.example.com 通过端口 2222 连接时？

您提供的 URI 语法在它可以表达的内容方面受到更多限制（它不允许文件名规范），更重要的是，除非实际主机名包含一个:（我不认为），否则永远不会有歧义在 DNS 中甚至是可能的，而且肯定不常见，而全数字文件名并不是那么不寻常）。

最初开发 SSH 时，它被开发为更安全的替代早期 RSH/rlogin 工具套件。我不知道 1990 年代早期的命令行语法是什么（描述 rlogin 的RFC是1991 年 12 月的 RFC 1282，比您引用的文档早了大约 15 年），但这似乎不是不合理的猜测它使用了非常相似的语法，因为用户名是在 rlogin 协议中专门传输的。引用 RFC 1282：

建立连接后，客户端向服务器发送四个以空字符结尾的字符串。第一个是空字符串（即，它仅由单个零字节组成），后跟三个非空字符串：客户端用户名、服务器用户名以及终端类型和速度。更明确地说：...

本地用户名可以通过各种系统工具获得，但远程用户名必须以某种方式明确指定。除了@经常发音为“at”之外，这是一个非常自然的选择，还user@host可以很好地映射到已建立的语法，例如电子邮件传输（比较 SMTP 地址user@host，其中host可能是实际主机或具有 MX 记录指向的 DNS 名称到实际的主机），所以这可能是一个简单的选择，而不是编造新的东西。

还值得注意的是 Stephane Chazelas 在评论中指出的内容：您所指的文件不是 RFC，它是一个目前已有七年历史的草案，从谷歌快速搜索确认来看，它似乎从未起步. 这一直在发生；提出了一些建议，但没有获得支持以将其真正纳入 RFC（甚至很多很多RFC 都是非标准的）。

Answer 2

ssh比更通用的 URI 格式 ( 1998 ) 早几年 (1995 IIRC)。