Почему команда ssh не следует RFC на URI?


9

RFC:

представляет SSH URI как:

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

Есть ли известные причины, по которым команда OpenSSH ssh не следует этому стандарту с опцией hostname? Он не принимает порт после двоеточия.

Пример URI, который я ожидал сработать:

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

Я думаю, что @ MichaelKjörling правильно. Двоеточие - это граница, где останавливается имя хоста, а путь начинается на этом хосте. Вы должны использовать -pкоммутатор для передачи альтернативного порта.
slm

6
Это не RFC, это проект, который не отслеживался с 2006 года.
Стефан Шазелас

Я согласен, что rfc3986 было бы более уместно процитировать.
Томаш Василюк

Ответы:


5

sshпредшествует более общему формату URI ( 1998 ) на несколько лет (1995 IIRC).


То есть вы говорите, что проект RFC 1738, опубликованный в декабре 1994 года, не мог повлиять на разработку OpenSSH? OpenSSH впервые появился в OpenBSD 2.6, а первый портативный выпуск был сделан в октябре 1999 года после Википедии . Разве это должно было быть совместимо с инструментами ssh.com?
Томаш Василук

RFC 1738 предназначен для URL-адресов и, по моим воспоминаниям, не является настолько универсальным форматом и позднее обобщается в URI. openssh намного позже ssh, я не помню, чтобы этот переход был выполнен, поэтому есть большая вероятность, что они в значительной степени совместимы с командной строкой.
Антон

14

Первоначально я опубликовал это как комментарий, но немного уточню это как ответ.

OpenSSH содержит несколько утилит, среди которых наиболее заметными являются sshи scp. Хотя sshбудет подключаться только к удаленному компьютеру (и, возможно, выполнить команду на этом удаленном компьютере), другие части OpenSSH, такие как scpимеют немного другой синтаксис. Благодаря тому, что они являются частью пакета OpenSSH, они, вероятно, имеют много общего кода.

С помощью scp, вы указываете удаленный файл в форме триплета как user@host:remotefilename, где remotefilenameможет быть относительный или абсолютный путь.

Если бы разрешено размещать часть узла в формеhost:port , это могло бы создать потенциальную неоднозначность: jdoe@host.example.com:2222ссылается ~jdoe/2222на host.example.com при подключении к стандартному порту или вообще не ссылается на файл (или, что еще хуже ~jdoe) на host.example.com при подключении через порт 2222?

Синтаксис URI, который вы представляете, более ограничен в том, что он может выражать (он не допускает указание имени файла), и что еще более важно, не может быть неоднозначности, если фактическое имя хоста не содержит :(что я не думаю, даже возможно в DNS, и, конечно, обычно это не делается, тогда как все числовые имена файлов не так уж и необычны).

Когда SSH был первоначально разработан , он был разработан как более безопасная замена для более раннего набора инструментов RSH / rlogin. Я не знаю, какой синтаксис командной строки для этого был в начале 1990-х годов (RFC, описывающий rlogin - это RFC 1282 от декабря 1991 года , предшествующий документу, который вы цитируете примерно на 15 лет), но он не кажется необоснованным думаю, что он использовал очень похожий синтаксис, потому что имя пользователя было передано специально в протоколе rlogin. Цитата RFC 1282:

После установления соединения клиент отправляет на сервер четыре строки с нулевым символом в конце. Первая - это пустая строка (т.е. она состоит только из одного нулевого байта), за которой следуют три ненулевые строки: имя пользователя клиента, имя пользователя сервера , а также тип и скорость терминала. Более подробно: ...

Локальное имя пользователя может быть получено с помощью различных системных средств, но удаленное имя пользователя должно быть как-то указано явно . Помимо того, что @часто произносится как «at» и, таким образом, является довольно естественным выбором для начала, он user@hostхорошо сопоставляется с установленным синтаксисом, например, для передачи электронной почты (сравните SMTP-адрес user@host, где hostможет быть реальный хост или имя DNS с указанием записи MX). на настоящий хост), так что это был, вероятно, легкий выбор, а не придумывать что-то новое.

Стоит также отметить, что Стефан Чазелас указал в комментарии : документ, на который вы ссылаетесь, не является RFC, это в настоящее время семилетний проект, который, судя по быстрому поиску в Google, похоже, никогда не сдвигался с мертвой точки. , Это случается все время; что-то предлагается, но не получает поддержки для фактического превращения его в RFC (и даже многие, многие RFC не являются стандартами).


1
Я предполагаю, что мой вопрос должен был быть «Почему утилиты OpenSSH не следуют общим стандартам URI?». Хотя я ценю ваше понимание, оно не ответило на мой вопрос.
Томаш Василук

+1 историческая перспектива полезна при картировании хаотического моря стандартов
Msw

Чтобы расширить комментарий «многие RFC не являются стандартами», это не может быть дальше от истины. Сама сущность RFC - это «Запрос комментариев»; это просто информация. Это может быть заметка, памятка или документация. RFC - это просто опубликованная записка; RFC - это просто один из многих способов публикации документации по стандартам, хотя это не единственная цель RFC. Стандарт может быть задокументирован с помощью RFC, но RFC не всегда является документацией для конкретного стандарта. Банан - это фрукт, но не все фрукты - это бананы.
Поворот
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.