Por que o comando ssh não segue o RFC no URI?

O RFC:

• Esquema Uniform Resource Identifier (URI) para SFTP (Secure File Transfer Protocol) e Secure Shell (SSH)

apresenta o URI SSH como:

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

Existem razões conhecidas pelas quais o comando OpenSSH ssh não segue esse padrão com a opção hostname? Não aceita uma porta após dois pontos.

Exemplo de um URI que eu esperava trabalhar:

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

sshantecede o formato mais geral de URI ( 1998 ) por vários anos (1995 IIRC).

Originalmente, eu postei isso como um comentário, mas o detalharei um pouco como resposta.

O OpenSSH contém vários utilitários, dentre os mais notáveis, são sshe scp. Embora sshapenas se conecte a um computador remoto (e possivelmente execute um comando nesse computador remoto), outras partes do OpenSSH, como scpuma sintaxe um pouco diferente. Em virtude de todos serem parte do pacote OpenSSH, eles provavelmente compartilham muito código.

Com scp, você especifica um arquivo remoto em um formulário triplo como user@host:remotefilename, onde remotefilenamepode ser um caminho relativo ou absoluto.

Se a parte do host tiver permissão para estar no formuláriohost:port , isso criaria uma possível ambiguidade: se jdoe@host.example.com:2222refere a ~jdoe/2222host.example.com ao conectar-se à porta padrão ou se refere a nenhum arquivo (ou pior ~jdoe) em host.example.com ao conectar pela porta 2222?

A sintaxe do URI que você apresenta é mais limitada no que pode expressar (não permite uma especificação de nome de arquivo) e, mais importante ainda, nunca pode haver ambiguidade, a menos que o nome do host real inclua um :(o que eu acho que não é até possível no DNS, e certamente não é comumente feito, enquanto nomes de arquivos numéricos não são tão incomuns).

Quando o SSH foi desenvolvido originalmente , ele foi desenvolvido como um substituto mais seguro para o conjunto anterior de ferramentas RSH / rlogin. Não sei qual era a sintaxe da linha de comando no início dos anos 90 (a RFC que descreve o rlogin é a RFC 1282 de dezembro de 1991 , anterior ao documento que você cita em cerca de 15 anos), mas não parece irracional. acho que ele usou uma sintaxe muito semelhante porque o nome do usuário foi transmitido especialmente no protocolo rlogin. Citando a RFC 1282:

No estabelecimento da conexão, o cliente envia quatro seqüências terminadas em nulo para o servidor. A primeira é uma cadeia vazia (ou seja, consiste apenas em um único byte zero), seguida por três cadeias não nulas: o nome de usuário do cliente, o nome de usuário do servidor e o tipo e velocidade do terminal. Mais explicitamente: ...

O nome de usuário local pode ser obtido através de várias instalações do sistema, mas o nome de usuário remoto deve ser especificado explicitamente de alguma forma . Além de @muitas vezes ser pronunciado "at" e, portanto, ser uma escolha bastante natural, user@hostmapeia bem a sintaxe estabelecida para, por exemplo, a transmissão de email (compare um endereço SMTP de user@host, onde hostpode ser um host real ou um nome DNS com um registro MX apontando para um host real), então provavelmente foi uma escolha fácil, em vez de inventar algo novo.

Também vale a pena observar o que Stephane Chazelas apontou em um comentário : o documento a que você se refere não é uma RFC, é um rascunho de sete anos que, a julgar por uma rápida pesquisa no Google para confirmar, parece nunca ter saído do papel . Isso acontece o tempo todo; algo é proposto, mas não obtém o suporte para transformá-lo em uma RFC (e mesmo muitas, muitas RFCs não são padrões).