Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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
share|improve this question
I think @MichaelKjörling is correct. The colon is the boundary for where the hostname stops and the path starts on that host. You need to use the -p switch to convey an alternate port. – slm May 13 '13 at 14:52
That's not a RFC, that's a draft that hasn't been followed through since 2006. – Stéphane Chazelas May 13 '13 at 15:36
I agree that rfc3986 would have been more appropriate to quote. – Tomasz Wasiluk May 15 '13 at 15:44
up vote 4 down vote accepted

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

share|improve this answer
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

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).

share|improve this answer
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 6 '13 at 22:49

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.