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

8

O RFC:

apresenta o SSR URI como:

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

Existe algum motivo conhecido por que o comando OpenSSH ssh não segue este padrão com a opção hostname? Não aceita uma porta depois de dois pontos.

Exemplo de um URI Eu esperava trabalhar:

$ ssh user@host:2222
ssh: Could not resolve hostname host:2222: Name or service not known
    
por Tomasz Wasiluk 13.05.2013 / 16:25

2 respostas

5

ssh é anterior ao formato de URI mais geral ( 1998 ) por vários anos (1995 IIRC).

    
por 13.05.2013 / 17:03
12

Originalmente, publiquei isso como um comentário, mas vou dar um pouco como resposta.

O OpenSSH contém vários utilitários, dentre os quais os mais notáveis são ssh e scp . Embora o ssh se conecte apenas a um computador remoto (e possivelmente execute um comando nesse computador remoto), outras partes do OpenSSH, como scp , têm uma sintaxe ligeiramente diferente. Em virtude de todos fazerem parte do conjunto OpenSSH, eles provavelmente compartilham muito código.

Com scp , você especifica um arquivo remoto em uma forma tripla como user@host:remotefilename , onde remotefilename pode ser um caminho relativo ou absoluto.

Se a parte do host tiver permissão para estar no formulário host:port , isso cria uma possível ambigüidade: o [email protected]:2222 refere-se a ~jdoe/2222 em host.example.com ao se conectar a porta padrão, ou não se refere a nenhum arquivo (ou pior, ~jdoe ) em host.example.com ao conectar-se pela porta 2222?

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

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

Upon connection establishment, the client sends four null-terminated strings to the server. The first is an empty string (i.e., it consists solely of a single zero byte), followed by three non-null strings: the client username, the server username, and the terminal type and speed. More explicitly: ...

O nome de usuário local pode ser obtido através de vários recursos do sistema, mas o nome de usuário remoto deve ser especificado explicitamente de alguma forma . Além de @ ser frequentemente pronunciado "at" e, sendo assim, uma escolha bastante natural, para começar, user@host é bem mapeado para a sintaxe estabelecida por ex. transmissão por e-mail (compare um endereço SMTP de user@host , onde host pode 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 criar algo novo.

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

    
por 13.05.2013 / 17:19

Tags