12

The RFC:

presents the SSH URI as:

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

Are there any known reasons why the OpenSSH ssh command doesn't follow this standard with the hostname option? It does not accept a port after a colon.

Example of a URI I was expecting to work:

$ ssh user@host:2222
ssh: Could not resolve hostname host:2222: Name or service not known
Community
  • 1
Tomasz Wasiluk
  • 123

2 Answers2

17

I originally posted this as a comment, but will flesh it out a little as an answer.

OpenSSH contains several utilities, among the most notable of which are ssh and scp. While ssh will only connect to a remote computer (and possibly execute a command on that remote computer), other parts of OpenSSH such as scp have a slightly different syntax. By virtue of all being part of the OpenSSH suite, these likely share a lot of code.

With scp, you specify a remote file on a triplet form as user@host:remotefilename, where remotefilename may be a relative or absolute path.

If the host portion was allowed to be on the form host:port, this would create a potential ambiguity: does jdoe@host.example.com:2222 refer to ~jdoe/2222 on host.example.com when connecting on the standard port, or does it refer to no file at all (or worse, ~jdoe) on host.example.com when connecting over port 2222?

The URI syntax that you present is more limited in what it can express (it doesn't allow for a filename specification), and even more importantly, there can never be ambiguity unless the actual host name includes a : (which I don't think is even possible in DNS, and certainly isn't commonly done, whereas all-numeric file names aren't all that unusual).

When SSH was originally developed, it was developed as a more secure, drop-in replacement for the earlier RSH/rlogin suite of tools. I don't know what the command-line syntax for that was back in the early 1990s (the RFC describing rlogin is RFC 1282 from December 1991, predating the document you cite by about 15 years), but it doesn't seem an unreasonable guess that it used a very similar syntax because the user name was transmitted specially in the rlogin protocol. Quoting 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: ...

The local username can be obtained through various system facilities, but the remote username must be specified explicitly somehow. Aside from @ often being pronounced "at" and thus being a pretty natural choice to begin with, user@host maps well to established syntax for e.g. email transmission (compare a SMTP address of user@host, where host may be an actual host or a DNS name with a MX record pointing to an actual host), so it was probably an easy choice rather than making up something new.

It's also worth noting what Stephane Chazelas pointed out in a comment: the document you refer to isn't an RFC, it's a currently seven years old draft which, judging by a quick Google search to confirm, seems to never have gotten off the ground. That happens all the time; something is proposed, but does not garner the support to actually make it into an RFC (and even many, many RFCs are non-standards).

Community
  • 1
user
  • 28,901
  • 1
    I guess my question should have been "Why do OpenSSH utilities not follow the general URI standards?". While I appreciate your insight it did not answer my question. – Tomasz Wasiluk May 15 '13 at 15:58
  • +1 historical perspective is useful in charting the chaotic sea of standards – msw Jul 06 '13 at 22:49
  • To expand on the comment "many RFCs are non-standards", this couldn't be further from the truth. The very nature of an RFC is a "Request For Comment"; it is merely informational. It may be a note, a memo, or documentation. An RFC is merely a published memo; RFCs are simply also one of the many ways standards documentation are published, albeit this is not the sole purpose of an RFC. A standard may be documented via an RFC, but an RFC is not always documentation for a specific standard. A banana is a fruit, but not all fruits are bananas. – Swivel Sep 10 '16 at 00:14
  • @Swivel doesn't this mean that the statement "many RFCs are non-standards" is true, if an understatement? Many fruits are non-bananas. – mwfearnley Dec 12 '20 at 08:54
  • 1
    @mwfearnley HAHA. Absolutely. I apologize. What I think I meant to say was: "To expand on the comment 'many RFCs are non-standards', this couldn't be more true." The timestamp shows it was about ~0:14 local time, so I was probably overdue for a snooze. (The irony, of course, is that I'm posting this at 01:59 local time right now). – Swivel Jan 05 '21 at 07:59
5

ssh predates the more general URI format (1998) by several years (1995 IIRC).

Anthon
  • 79,293
  • So you are saying that the draft of RFC 1738 published in December 1994 could not have influenced OpenSSH development? OpenSSH first appeared in OpenBSD 2.6 and the first portable release was made in October 1999 following Wikipedia. Unless it had to be compatible with the ssh.com tools? – Tomasz Wasiluk May 15 '13 at 16:14
  • RFC 1738 is for URLs and was in my recollection not so generic a format and later generalised in URIs. openssh is much later as ssh, I don't remember having made the transition so there is a good chance they are commandline compatible to a large extent. – Anthon May 15 '13 at 16:27