How SSH port became 22 (2017) | Hacker News Reader

How SSH port became 22 (2017)

ssh.com

408 pointssysoleg176 comments

> I designed SSH to replace both telnet (port 23) and ftp (port 21).

As I have written here previously¹, that’s actually a bit of revisionist history, or at least a significant omission. Speaking as someone who was actually using Unix systems when this happened, the "ssh" command was replacing the rsh command, and also still ships an "slogin" command, replacing rsh’s companion command, "rlogin" (and "scp" replaced "rcp"). Where I was, nobody was even using telnet or FTP internally; everybody was using rsh, rlogin and rcp! This also better explains the naming; going from "rsh" to "ssh" is easier.

If someone had wanted to make telnet encrypted, they would just have had to implement the standard telnet protocol and add another option in the protocol; it has a bunch already, and even one for encryption, IIRC.

1. <https://news.ycombinator.com/item?id=14178333>

> If someone had wanted to make telnet encrypted, they would just have had to implement the standard telnet protocol and add another option in the protocol […]

    This document describes a the telnet encryption option as a generic
    method of providing data confidentiality services for the telnet data
    stream.  While this document summarizes currently utilized encryption
    types and codes, it does not define a specific encryption algorithm.
    Separate documents are to be published defining implementations of
    this option for each encryption algorithm.

* https://datatracker.ietf.org/doc/html/rfc2946

So I did recall correctly, then.

> Speaking as someone who was actually using Unix systems when this happened, the "ssh" command was replacing the rsh command,

A different data point: I was also a Unix sysadmin at the time (thought just out of school) and for me ssh replaced telnet and ftp. I never used rsh, rlogin, and rcp except when testing exploits.

In my experience, telnet and FTP were used when accessing external resources; when wandering around the local menagerie of machinery, rsh, rlogin and rcp were predominant.

Telnet predates UNIX and came from the late 60s; rsh/rlogin were introduced by BSD in the 80s. So if you were in a BSD-derived system, you might have used rsh/rlogin, but otherwise telnet was the standard. Telnet was also cross-platform; I first used it on VMS.

Ditto, I had been doing sysadmin as my job for a few years in 1995 and as a component of my job or as a hobby for ~5 years before that. I was decidedly a telnet/ftp guy before ssh, and dabbled a little with "ssltelnet". I mostly avoided rsh and family because I didn't love the security model.

SSH was a fantastic improvement at the time, though the whole licensing model interfered with my use for the first several years.

My experience as well.

Much depends on whether your systems were running BSD-style RPC services.

Oh, rsh, your security model was so cute. It runs on port 513. (There is also rexec, port 512, and rcp on port 514. rlogin runs on port 513 along with rsh.)

Berkeley compute facilities used $rsh and $rlogin .. not clear on the file transfer from the outside. Dial-up modem from a residential phone line in those days, this was before 9600 baud became common for individuals.

ftp on the other hand was more like finger or similar.. going to some external site that was public, or had a login to distribute files.

I think it's a bit unfair to call it revisionist. It's a direct claim by the author of ssh, and out of all the ports numbered 1-255, telnet (23) does come closest in function to ssh. I believe the article is more about how lucky the author got to nestle a port between two other protocols that ssh superseded, rather than the thinking behind the naming of the ssh family of protocols.

He included the letter he wrote to IANA so, unless you are calling fraud, it is actual history rather than revisionist history.

In that letter he says: “It provides major improvements in security and functionality over existing telnet and rlogin protocols”.

So, while you are correct about rsh, it seems totally fair ( and likely just correct ) for him to say he chose port 22 for its proximity to telnet. Also, since SSH includes SFTP, what he says about FTP checks out as well.

The story is about “why 22” and telnet answers that question better than rsh does. I guess if the question was “why ssh”, the details you added would matter more.

Without having any specific information on the matter at hand: revisionist history does not need fabricated facts. Its very possible to revision history by omitting crucial parts. Hence the letters might be genuine and someone revisions history by leaving out other relevant information.

"The -p <port> option can be used to specify the port number to connect to when using the ssh command on Linux. The -P <port> (note: capital P) option can be used with SFTP and scp."

The most annoying thing about SSH/scp!

I always just use -o port=<xx> for this reason.

Wait, lower case 'o' works?

Looks like I've got BSD SSH installed. From `man ssh`:

     -o option
             Can be used to give options in the format used in the configura‐
             tion file.  This is useful for specifying options for which there
             is no separate command-line flag.  For full details of the op‐
             tions listed below, and their possible values, see ssh_config(5).

`Port` is on the list underneath. So I think the idea is you run

    ssh -o <option_name> <option_value>

where the first can be `--port`. This looks like it will be really handy for me for the exact reason GP said.

I use rsync with -e 'ssh -p PORT', so that I can also have the ability to resume just in case :D, interesting how everyone has a different solution ^^, let's see how many ways of doing the same thing can we collect in this thread

Another one is places where you can use `user@host` and those where you can't and have to use `-l user` (and thus have to use `-e 'ssh -l user'` or equivalent)

Usually I use per host `ssh_config(5)` (both for port and user) but some tools also don't make use of that!

Use ~/.ssh/config to add per host or wildcard values for port :)

This right here is the next big trick behind using CTRL+R to find the last ssh command.

~/.ssh/config is one of the simplest, most useful features I use on a daily basis. It would be easy to accomplish much of it's behavior even if it didn't exist (bash script for each account@host), but it wouldn't be as elegant.

The config-aware shell completion is especially cool.

My most recent pet hate is inability to instruct scp to ignore symlinks -.-

Huh. You're right, and it's a WONTFIX: https://bugzilla.mindrot.org/show_bug.cgi?id=485.

I hadn't even noticed, because I tend to automatically reach for rsync instead, even for single files.

Interestingly enough that ticket is about preserving and/or following - I would be happy with ignoring so it doesn’t end up in an infinite loop - as it stands a self referencing symlink with files in the same directory will result in either your disk filling up, your inodes filling up, or a maximum bested paths error (assuming your FS has such a thing).

Edit: and until the ticket you just linked, I assumed scp and cp were intended to be close equivalents, given the whole ending in ‘cp’ thing.

Great if you only ever ssh from your primary box/profiles, an amplifier of the problem (due to entering the commands less often) otherwise!

I use this for aliasing as much as for Port assignment.

What's even more annoying is that -P for scp has to be put before the target while -p for the ssh client I am using can be put after the target.

So when you write your scp command and then realize you forgot to put in the port you have to go back and put it before the target.

The most annoying thing about SCP is args ordering, I would have preferred a single direction arg for transfer details, if it meant we didn't have to worry about positional args.

Then again, I'm speaking as someone that came into the scene well after development, so that could just be annoyance via naivete.

Even more fun when you are doing ssh, scp and throw in some random nmap in there as well, where -P and -p are both used.

Add the lowercase -r for recursive scp and you have two screens with man pages open.

This tripped me up hardcore at work recently, because I was trying to SSH into a VM using a non-standard port, but the port-forwarding went from the non-standard port into the usual 22 on the VM. So when I got "Connection Refused" on port 22, I thought that meant the connection was getting through the NAT layer but then failing at the VM for some reason.

NOPE I'd just specified the option wrong!

Agreed :). I always have to google which case applies where as I use ssh and scp heavily.

Announced officially to the mythical cypherpunks@toad.com mailing list...

Fighting to legalize cryptography on the internet. PGP was banned. Sending encrypted emails was illegal...

Cypherpunks won. Thanks to them.

Conspiracy-minded theory: only once the government successfully arranged for a process (behind closed doors) to subvert or capture any US-based cryptography efforts or communications.

Where were you that PGP was banned, or encrypting emails was illegal?

Cryptography was considered a war weapon and only allowed for military use.

The United States had to be brought to court to finally allow cryptography: https://en.m.wikipedia.org/wiki/Bernstein_v._United_States

> Years before, the government had placed encryption, a method for scrambling messages so they can only be understood by their intended recipients, on the United States Munitions List, alongside bombs and flamethrowers, as a weapon to be regulated for national security purposes. Companies and individuals exporting items on the munitions list, including software with encryption capabilities, had to obtain prior State Department approval. — Electronic Frontier Foundation: EFF's History

Before that, export rules could be "worked around" by printing cryptography in books.

not quite crypto related, or at least directly, i remember this old Mac G4 ad: https://youtu.be/lb7EhYy-2RE?si=3tvJK4BXbA71LbGQ

> Cryptography was considered a war weapon

It still is.

e.g in France:

https://cyber.gouv.fr/en/protection-sensitive-and-restricted...

    This legal framework has been introduced in 2011 in order to protect facilities, knowledge, savoir-faire, information which, if intercepted, could:
    
    - Affect French economic interests (risk 1);
    - Reinforce military capacities of other country or weaken French military capacities (risk 2);
    - Lead to the proliferation of weapons of mass destruction in nuclear, ballistic, chemical or biological fields;
    - Lead to the development of terrorist activities on French territory or abroad.

It's just that import/export constraints have been relaxed.

See Annexe 1 here: https://www.legifrance.gouv.fr/loda/id/JORFTEXT000000646995?...

This is one of the reasons why MobiusSync is not available in the French iOS App Store since it doesn't use iOS crypt which already has approval plus it doesn't fit into some of the exceptions to the restrictions, so they'd have to fill in paperwork which is only available in French and submit via snail mail (go figure, although they do accept answers written in English as a courtesy).

https://github.com/MobiusSync/MobiusSync/issues/27

Similar concerns, processes, and exceptions are effective for other countries, e.g for the U.S. you need Encryption Registration (ERN) approval from the U.S. Bureau of Industry (BIS). Exceptions are described in Category 5, Part 2 of the U.S. Export Administration Regulations.

"You have to get an export license if you're distributing from inside the US to outside the US" is pretty different to "sending encrypted emails was illegal", no?

For one thing, it sounds like sending wasn't impacted at all, once you had the software.

How would you send encrypted email without an encryption library?

From what I remember, what was illegal was exporting a (useful) encryption library, and that Wikipedia link supports my memory: It talks about exporting munitions. I remember at the time that even though libraries existed inside the US they weren't supposed to be exported to other countries (i.e. the rest of us should get encryption libraries developed outside the US). Nothing prevented US citizens in the US to use encryption. Nothing in that "cryptography is considered munitions" legal issue, at least, because that was about export.

They can't use encryption if they can't get encryption software. I recall hearing that companies outside the US could distribute software with competent encryption without problems (to people inside and outside the US), but companies inside the US basically couldn't distribute software with competent encryption, because someone outside the US might download it.

But I remember the time. The software could be downloaded from inside USA. Mid-nineties the internet wasn't particularly large and (what's nowadays) simple measures were in place. In practice you could get it from the US even if you were outside, but then again USA wasn't the only place where encryption software was made, so we all thought it a bit silly.

What I'm getting at is that it's simply incorrect that encryption wasn't available in the US, and it's also incorrect that encryption couldn't or wasn't in use. It most definitely was. The regulations were only about export. 40 bits max and all that.

I understand where you're getting at, but lawyers would see "is it possible for people out of the US to download this? Yes? Well lawsuit incoming, by the government/military."

This is way too much of an unknown. And we've seen with P2P/Napster and DMCA where just listing links without distributing still opens people to legal issues.

Those of us who were active back then did see the software. It was not kept off servers. It's just that I don't think archive.org was active at the time so we have no way of showing it to you, I believe.

Edit: As for Napster and DMCA, the Napster story happened in 1999 and the DMCA in 1998. The limitations on crypto were loosened in 1998 and 1999 and removed in 2000. In other words, Napster and DMCA isn't really relevant here - the encryption story mostly unfolded before that time.

You are speaking past the GP by missing the de jure (their point) versus de facto (your point) aspect of the discussion, I think.

Possibly - but my impression is that the GP is rejecting as impossible what I'm stating - that in fact you could use cryptographic libraries in the US, because they were, indeed, available. GP seems to argue that they could not have been available because that would have allowed them to potentially be downloaded (exported) outside of the US, which was illegal at the time.

None of this is true. It really feels like there are a couple people who were, like, alive in the 1990s trying to explain to people that cryptography was not in fact illegal or even regulated in the USA during the heyday of Ace of Base, and then a lot of younger people trying to axiomatically derive an alternate history where nobody could encrypt anything. You could just download PGP and run it, and if you go look at back issues of Wired, you'll see that lots of people were begging Americans to do just that.

The fact that it was not enforced doesn't mean there wasn't a sword of Damocles above your head.

As someone who watched all of that at the time.. I believe nobody in the US felt any sword of Damocles above their heads. The net was a very different place from now. A simple automated download check was what was needed, or even just a statement. There was other kind of software as well, and I remember having to fill out a form stating that I wasn't going to re-export the software to [short-list of certain countries] before I got the actual download link. That was about it, back then.

What would that check do? Check IPs?

Some companies literally just provided two links, one for the US version and one for the international version. That's how not-serious this whole thing was.

Really, even back in 1995, people did understand how the Internet works. Nobody was under any illusions that you could actually control "export" of cryptographic software. If you were a US-based company that sold shrink-wrap software, you probably also filled out some paperwork once a year. For "open source" software (note: not a thing, as such, in 1995): forget about it.

geoiplookup wasn't a thing until 1999 or so, plus/minus, but "whois" was, and mid-nineties the net was pretty small compared to now (for a definition of "small"). So yes, knowing where an IP address came from was a thing even then. But there were also the two-versions links mentioned by the sister comment. Among other things. This was not a big deal. Really.

There was nothing to enforce. This concern is made-up. Again: the people telling you this were there in the 90s, in the workforce, "dealing with" this stuff. The far bigger problem was that the maintainers of Apache's SSL code wanted a license fee to use it. I do get that if you were 7 years old at the time, and in France, it might have seemed complicated, because of the (unenforced) export rule, but that rule didn't matter to Americans or in any meaningful way restrict our access to encryption.

You (as a US citizen or company) would acquire one from a US vendor. Exporting outside the US was illegal, using it within the US was not.

How would US vendors prevent people from outside the US to acquire the software?

They put a notice above the download link that said it was illegal to export to certain countries. Really. The onus was on the person downloading the software, not the person providing it.

You would use an "encryption library"? I don't understand what's complicated about this. I thought perhaps that top comment was talking about some country other than the USA, where cryptography had actually been outlawed, but it seems people really believe the US outlawed crypto in the 1990s? No, they did no such thing. They didn't even regulate it, excepting export controls.

Sending encrypted email in the US was NOT illegal. Sharing encryption libraries was.

How would you send encrypted emails without an encryption library?

You're not reading or comprehending the multiple correct replies. I won't repeat them because apparently that won't get through to you, but you should go back and read them again and again until you understand, or at least stop repeating the same incorrect information, if not finally understanding the correct information people keep trying to tell you.

https://en.wikipedia.org/wiki/Sealioning

woah I'm so glad he did it, I now got better picture of twitter altogether.

I am reading the replies.

You don't understand the legal liabilities people open themselves to if they provide the software.

Now they have to fully KYC customers to make sure they are from the US, with US only storage, and firewall so that people travelling cannot use the encryption library from out of the US.

You've seen the lawsuits on just P2P link providers, this is even worse.

People inside the US could trade encryption libraries. They just couldn't send those libraries to outside the US. You could download a cryptography library from outside the US, and your foreign recipient could do the same, and thus send emails back & forth. In practice all it meant was that US developers couldn't write make useful cryptography libraries, and the development got done elsewhere.

The US still restricts the export of (some) cryptography to (some) countries & organizations. Mostly that just requires submitting a self-classification report to the BIS stating that the cryptography is "mass market" and matches the definition thereof in the export regulations.

But what happens if the company you're trading with has non-US entities? Or traveling salesmen?

The issue here is the complexity of complying and closing all loopholes that would allow the government to bring the full weight of the legal system against a library writer.

Nothing happened. Nobody cared.

That's an oversimplification and also inferring a completely incorrect situation.

It was perfectly fine for American citizens to use cryptography amongst each other or with outside nationals. It was also completely fine to download and use externally developed software.

What was illegal was developing and exporting cryptographic software. This is why, for the longest time, you would see warnings on web pages (puTTy, for instance) saying the software was only intended for use in the United States.

I remember publishing some apps to the iOS App Store and was asked to “declare cryptography to the US government”. I’m not even American.

The form made it clear that using HTTPS is considered cryptography, so I’m fairly sure almost every app on the store has checked “yes” to that question.

I disagree.

To fully comply with this you would need as a library provider to fully KYC your clients so that there is a firewall between their US and non-US entities, and that travelling people don't bring out an encryption library at the same time.

It would be a operational nightmare.

In the time period we're discussing, I was on a team shipping a commercial (shrink-wrap!) software project that extensively used cryptography, including an export version of same. It was not a big deal; it was not an operational nightmare; in the North American market, it wasn't a thing at all, you just did whatever you wanted.

Which part are you disagreeing with? I'm literally laymaning the law.

The law never covered using cryptography, it was always about exporting it. Mostly it was written around keeping military specific cryptography from entering rival powers hands, but was overbearing. So they amended it to allow commercially developed/homegrown cryptography (explicitly not developed for governmental/military use) to be distributed normally. In practice, it's still a little muddy as many of those use DoJ/DoS-funded cryptography patterns, but the government has chosen to take a fairly hands off approach on those (RSA and DSA are key examples).

You're correct that it would also be almost impossible to enforce the original wording in today's world of globalization. They also have little power to enforce it on foreign nationals, which is why a warning was usually Good Enough(TM) for American software developers.

Using is exporting though. If you made a client that had https, and a customer downloaded it in Toronto, you were breaking the law.

This is....yes, the exact point; thank you for finally getting to what everyone was saying from the outset. Now follow the conversation forward.

Re-read the first post and the last paragraph of the one you're replying to. Everything you're knee jerk contrarianizing is covered.

So far as I'm aware, this was never the case. Bernstein's case started in 1995 (it was decided in 1999). I assure you, cryptographic software was widespread and, apart from export controls, unchecked in 1995. Source: my professional career started in 1995.

In (I think) early 1995 I bought a "This T-Shirt Is A Munition" shirt with RSA source code on it, by typing the information from the bottom of a personal check(!) into a web page. It was a whole thing.

You are probably from the US and not aware how things looked outside of it? https://en.m.wikipedia.org/wiki/Crypto_Wars

Quite recently, the researchers behind the Tetraburst attack (https://www.tetraburst.com/) discovered that Tetra's encryption has "levels" which depend on the intended recipient's country.

This leaves the critical infrastructure of emergency services and police force for a lot of countries (notably, US non-allies) wide open to attack.

The existence of the levels was previously known; what they discovered was just how bad some of them are.

PGP was not exactly banned but if you were in Europe when ITAR restricted its export, and you were trying to download from strait-laced corporate types like AOL, they wouldn't let you.

And even if a determined person could get around the blocks, they severely limited the network effects; office workers on their employers' PCs weren't going to be getting encryption software from IRC bots to bypass arms export laws.

Some time towards the late 90s PGP became much more easily available.

Its effects are still with us. Hardly anyone uses encrypted email even though it is now easy to set up. The (lack of) network effects has persisted.

IMO that's less due to the ease of setup and more due to the lack of any sane key exchange system & general impossibility of encrypting all email content (e.g. subject line).

Encryption was (and in some countries, still legally is) considered dual use technology. You needed to go through paperwork and licensing to export cryptography across the border. Symmetric keys longer than 64 bits were considered too strong.

This led to all kinds of stupidity. Internet Explorer shipped with nerfed TLS capabilities, limiting key sizes to 40 bits or 56 bits depending on the version.

When the encryption laws changed in 2000, Microsoft allowed users to download an update to improve SSL encryption: https://learn.microsoft.com/en-us/previous-versions/tn-archi...

You could legally encrypt emails, of course, as long as you kept the key sizes small and didn't export the encryption software to another country.

If you sell and export encryption products from the USA (and a bunch of other countries, see the Wassenaar Accords) to certain places (including China and Russia), you're still obligated to register your product if you use modern key sizes. I'm not sure if governments still care now that OpenSSL and PGP are freely available to anyone, but if your proprietary email encryption program is found on North Korean computers, your government may ask you some uncomfortable questions.

As discussed on thread, not banned, but posting it somewhere could get you in significant trouble. In fact, Phil Zimmermann got in quite a bit of trouble for his contribution towards the world getting a hold of PGP, which was considered a export restricted munition. I believe there was at least one court case, harassment, tax audit, and hassle at the border. My memory is a big vague, but you get the idea.

I was at codecon, forget if Zimmerman was there, or just quoted. His story was recounted, then someone else who attended codecon and mentioned releasing ITAR restricted crypto. They were part of a leak of the RC4 source code. A copy was sent to a well known member of sci.crypt, saying along the lines of "I think you can post this anonymously", if you agree to this please post a "Looking for Joe Random" post on sci.crypt. The source code was posted and there was no lawsuit, no tax audit, and no hassling by the government.

This quickly led to a cottage industry of instructions on how to write your own RC4 CipherSaber util - https://github.com/search?q=ciphersaber&type=repositories -- http://ciphersaber.gurus.org/faq.html

I was on the Cypherpunks list, mostly as a lurker. The technical discussions were amazing. I was really into it at the time, but now I find some of the political ideas to be embarrassing.

Other people had a lot to do with the spread of strong crypto as well. Many people realized that encryption was necessary if we wanted to do business online. Matt Blaze (who was on the Cypherpunks list, but never said anything crazy), helped blow up the government's compromise solution, mandatory key escrow, by demonstrating flaws in their Clipper chip technology. The MIT Press published PGP's source code in book form, using an OCR font, because books couldn't be blocked as munitions. I think Hal Abelson, who wasn't on the list, was the person behind that.

The basic political idea behind the list was that you could effect change by writing code. Instead of going to the government, with your cap in your hand, and saying, Please, sir, can we have strong encryption?, you write code and give it away, thus making the law impossible to enforce. This sounds really cool when you're young, especially if you write code, but it's an anti-democratic idea.

The political positions of some of the leaders was kind of an extreme, anarchist spin on libertarianism. Bitcoin is a currency designed to solve a specific problem -- it's kind of the ultimate solution to the old goldbug fear that governments will print money and dilute the currency. That's impossible under Bitcoin.

The original crypto currency the Cypherpunks were really into was David Chaum's Digicash, which was designed to solve a completely different problem, the same one Monero is aimed at today. It was supposed to be untraceable. Instead of asking governments to lower taxes, the idea was that programmers could create a way to transfer funds anonymously. In theory, taxes would become impossible to collect, and national borders would collapse.

Eventually this led to things like discussions of anonymous murder contracts. There was a proposed protocol that was supposed to allow you to put out a hit on someone with complete safety. You could pay the killer anonymously with digital currency. I think the payment would go into some sort of escrow, so the killer would know they'd get paid. I don't remember how the system was able to know that the hit had taken place.

Those murder contracts were one of the things that made me pull back from the list. But it really was terrific to read, even though I think it would be a mistake to lionize it too much. Arguably, they were struggling to make the whole world run on 8chan's rules.

> This sounds really cool when you're young, especially if you write code, but it's an anti-democratic idea.

Is it? Code was deemed free speech, after all. So suppressing it would be anti-democratic, not spreading it.

I -think- the anti-democratic thing is making it impossible to enforce the laws of a democratic society. If a democracy decides that strong encryption should be banned, going against that is going against the will of the people.

Of course, we all (technical people) agree that it was the right thing, but ask yourself: If there was a vote on the issue, do you think the majority of people would vote for keeping strong encryption, or do you think they'd ban it? Especially back then.

I personally think they'd ban it. I bet the majority would just go "encryption is for terrorists and bad people, we don't need it", and we'd lose the vote.

Democracy is funny that way.

Now for an alternative thought exercise consider the situation in which a democracy votes to end itself and initiate a dictatorship. Is it democratic or anti-democratic to try to stop it?

Rather than speculate, let's just wait a few months.

Although the end of the Weimar Republic was essentially an electoral choice, significant chunks of the electorate by then had been skewed, divided, disenfranchised, or even displaced it wouldn't be accurate to call the elections fully representative. And yes, similar efforts are underway in the US too.

> Democracy is funny that way.

Democracy is just a tyranny of the masses.

Through the good advertising it's now usually understood as 'we vote => we are in control => values', except democracy is clearly has nothing with social and humanitarian values.

Is it? That's clever sounding but mostly wrong.

Democracy is a system where political disagreements are resolved through a set of agreed-upon rules (AKA "rule of law") instead of violence. The alternative to Democracy is mass murder. There is still plenty of violence in a Democracy -- witness the prison system in the USA, but it isn't neighbors just casually murdering each other (as also happened in the USA in an organized way in the Jim Crow era). Interesting to note -- both counter-examples were / are founded on denying parties participation in the democratic process...

The Rwandan and Bosnian civil wars are both examples of "tyranny of the masses" where there's no mechanism for resolving disputes between groups, besides killing your neighbor.

How SSH got port number 22 - https://news.ycombinator.com/item?id=33363795 - Oct 2022 (2 comments)

How SSH Port Became 22 - https://news.ycombinator.com/item?id=21350246 - Oct 2019 (81 comments)

How SSH port became 22 - https://news.ycombinator.com/item?id=17552100 - July 2018 (95 comments)

How SSH got port number 22 - https://news.ycombinator.com/item?id=14178091 - April 2017 (207 comments)

(2017)

Was this article updated recently in some way? Not sure why it's mentioned at top of page, maybe just appended for posterity.

HN discussion then: https://news.ycombinator.com/item?id=14178091

Ah thanks! I've updated the list above.

Why 22 was available is also interesting. Network Control Protocol was the precursor to TCP and used different ports for inbound and outbound traffic, typically even for outbound and odd for inbound.

If you look in /etc/services you'll notice that all the older protocols listen on odd numbered ports.

Some of this still survives today. In active mode FTP servers listen on 21, ACK the inbound request and then connect to the client from 20.

I do not miss the days of trying to figure out which FTP mode would work through a given firewall configuration.

Had a very similar experience when I requested a Private Enterprise Number (PEN) in the early 00s.

I was doing some experimentation with LDAP, mailman and identity based encryption and needed some OIDs to support my undergraduate project work.

Private Enterprise Numbers are identifiers that can be used in SNMP configurations, in LDAP configurations, and wherever the use of an ASN.1 object identifier (OID) is appropriate.

So I went about signing up my university for a PEN. It helped that I also worked for the IT Services team at the time but I distinctly remember the request being done by email with the response more of less being "here's your number". :)

To my knowledge, I believe I'm the only person who has made use of the PEN assigned to the university.

    From: Tatu Ylonen <ylo@cs.hut.fi>
    To: Internet Assigned Numbers Authority <iana@isi.edu>
    Subject: request for port number
    Organization: Helsinki University of Technology, Finland

Was "Organization" a common email header at the time? This is the first time I see it.

Many e-mail client still has a field for it in its account settings.

Yes!

“Can I have port 22?”

“Yes”

the early days of the internet are so fantastical to me I can’t stand it. Makes me sad to be too young to have witnessed it.

The early days of the internet were dominated by InfoSeek Net Search, then later on Alta Vista was the search engine of choice. Then later on, Google appeared and everyone else couldn't compete.

That's closer to an abridged history of "World Wide Web" search engines.

The internet was decades old when Infoseek appeared.

the internet was decades old when http appeared.

Was it DEC than ran Alta Vista? They were involved in some search engine

Indeed.[1]

I recall using it as my main search engine at altavista.digital.com before they moved to get its own domain at altavista.com.

[1] https://en.wikipedia.org/wiki/AltaVista

I remember when AltaVista was the best, and despairing because it was so terrible.

At a dinner party, we were arguing about how to move forward with discovery on the web, because the situation was so dire. Someone was arguing for keyword registration, a la AOL.

I really, really hope that someone wasn’t me; I’ve convinced myself over the years it wasn’t, but I didn’t have any better ideas, just knew that wouldn’t work.

I was using Archie and gopher in the late 80s. Do you mean web search instead of internet search?

> The early days of the internet were dominated by InfoSeek Net Search

That's 20-some years after the early days of the Internet.

I'd been using the internet for 14 years before InfoSeek Net Search appeared in 1994, this is honestly the first time I've heard of it.

I don't even consider myself an early user of the internet either, the people I learnt from had already been using it a good while.

There was also that time Jon Postel asked all the DNS root server operators to make his server the root, and they did. https://www.wired.com/2012/10/joe-postel/

Ah yes back when NANOG was an irc channel and anyone could join and discuss their routing problems.

It was a simpler time for sure

You don't really need permission to take a port; you can run your service on 80/tcp if you like.

Here it's different than this, the question is rather "Can it be recorded that port 22 is reserved for my tool so it becomes a worldwide convention?"

There is no worldwide convention. Go ahead and run your services on whatever ports. That's what I do.

Yes there most certainly is a worldwide convention. Please read the article before commenting. Just because you don't happen to follow the convention does not mean it doesn't exist and isn't worldwide.

No convention at all, just FTP defaulting to 21 and SSH to 22 and websites to 80 randomly.

There is no Internet Police that will give a fine for using the 'wrong' ports.

(In fact, not running SSH on port 22 is an industry best practice in 2024, sadly.)

You are thinking of a law, not a convention.

A convention is a common language. It is something you have the right to break when needed / suitable but which is otherwise nice to follow when interacting with others.

Such conventions allow you to omit the port when typing a URL in a browser for instance. They allow taking nice shortcuts and avoiding verbose / irrelevant technical details.

(now, some conventions are mandated by laws indeed. For instance, if you are setting up electricity somewhere, you'd better use the right colors. One might argue that we ought to call such things rules)

Conventions are defaults. Every browser I have assumes port 80 (or 443) for http (or https) by default for a reason.

> There is no worldwide convention.

Yeah, if only there were an authority that we could agree on to assign numbers for internet things like ports.

Some sort of internet assigned number authority…

https://www.iana.org/assignments/service-names-port-numbers/...

You can, but you'll have to deal with the consequences of violating conventions and the impact of that might matter very little or a whole lot depending on the situation. Running a random service over port 80 can be a good idea (lots of networks have that port open), but you'd better be willing to deal with the traffic from people/bots/crawlers looking for a webserver there. If you aren't careful you can break things on your own network or get yourself cut off from others. The rules and standards that exist are there to make everyone's lives easier and promote things working. Deviate from them at your own risk.

Even if you were old enough, you probably wouldn't have witnessed it because it was only being worked on by a small number of people. There must be amazing future things which are in their early days right now but you and me aren't involved with them and nobody knows for sure what they even are until they explode.

I'm old enough to remember the early days of Bitcoin and how nobody I talked to about it had ever heard of it and was either dismissive ("That would be easy to hack" / "that can't work") or just treated it like a random chit-chat that didn't matter.

Wow that's a lot less negotiation than is required to tell a TCP joke! ;)

  Hello, would you like to hear a TCP joke?

  Yes, I'd like to hear a TCP joke.

  OK, I'll tell you a TCP joke.

  OK, I'll hear a TCP joke.

  Are you ready to hear a TCP joke?

  Yes, I am ready to hear a TCP joke.

  OK, I'm about to send the TCP joke. 
  It will last 10 seconds, 
  it has two characters, 
  it does not have a setting, 
  and it ends with punchline.

  OK, I'm ready to hear the TCP joke 
  that will last 10 seconds, 
  has two characters, 
  does not have a setting, 
  and will end with a punchline.

  I'm sorry, your connection has timed out...

  ...Hello, would you like to hear a TCP joke?

OMG, this is brilliant! How have i never heard this one before!?! Thanks for sharing! :-D

I'd tell you a UDP joke, but you might not get it. ;)

OMG another good one! :-D

I’ve always wanted to see something like a common port dictionary or encyclopedia. Just a big list of all the ports, each with their common usage and the history behind it.

There's this wiki page that's pretty cool https://en.m.wikipedia.org/wiki/List_of_TCP_and_UDP_port_num...

Wikipedia's list is better than the official one because it explains what some of those protocols actually are – especially the early ones which don't have any RFC specified in IANA's registry.

Although, in several cases, there is an RFC, even though IANA's registry doesn't record it. For example, port 1 (tcpmux / TCP Port Service Multiplexer) uses a protocol defined by RFC1078, as Wikipedia's article on it helpfully explains – https://en.wikipedia.org/wiki/TCP_Port_Service_Multiplexer – but IANA's registry doesn't mention that.

Or similarly, port 5 is listed as rje / Remote Job Entry in the registry, but Wikipedia helpfully notes that it is the protocol defined by RFC407 (and maybe RFC725 is a newer version of it?). I doubt that ARPANET RJE protocol (whose syntax resembles FTP, SMTP, etc) ever saw any great amount of implementation; I believe historically the most popular RJE protocols were IBM's (2780/3780 and later Network Job Entry / NJE which was used in RSCS, most notably on BITNET) – but those protocols don't have an assigned port number, since they don't natively run on top of TCP/IP.

There are however some historical mysteries in this IANA registry for which even Wikipedia does not know the answer: the first of many is what ports 2 and 3, "compressnet", were used for. (Edit: What Wikipedia doesn't know, HN does: https://news.ycombinator.com/item?id=37016159

Seconded. I made some Anki cards out of the table of the "Well-known ports" table and it has proven surprisingly helpful fingertip knowledge for my kind of work (Linux systems and small scale networks in odd places).

Notably: port 666 - "Doom, the first online first-person shooter"

I'd like to see that email to IANA.

I mean if we wait long enough everything will be on port 443...

Questions from the distant future: "Why is there this hardcoded 16-bit field in the UDP header which is always 443? Why do we have an IPv6 header which is always followed by a UDP header which is always followed by a QUIC header? Why not just merge the three headers into one?"

And then RFC99999 defines a "new protocol" in which there is just a single header, which happens to have the same byte layout as IPv6+UDP+QUIC, with a bunch of fields like "reserved_01BB" which "always contains the bytes 0x01BB due to historical backward compatibility reasons"

> Why do we have an IPv6 header

Ah you’re an optimist I see

You can start with the IANA list [0]. You won't find posts like this listed but it should be a good place to start regardless.

[0]: https://www.iana.org/assignments/service-names-port-numbers/...

On Linux, /etc/services often contains a list of at least protocol names and numbers.

Nmap ships with an nmap-services file, which is a lot like /etc/services. However, you might find it interesting because it lists common worm backdoor ports rather than some obscure license server.

One fun list is in the default NetComm router software which still has a huge list of pre-saved port forwarding info for multiplayer PC Games that hasn't been updated since around 2001. That's quite a fun nostalgic list to browse.[1]

[1] Here's A-D: https://i.imgur.com/tCn2FBB.png

> We have assigned port number 22 to ssh, with you as the point of contact. Joyce

Those were the early days when you could be designated as the point of a contact for a TCP port connection number and expect not to be swamped by emails!

I used to have a registered port (in the 3000s) - didn’t get a lot of spam, but once I got a very angry phone call (!!!) from someone that tracked me down because their firewall blocked an incoming request in that port. They did their own research and decided it was my fault.

I always figured FTP is port 21, SFTP/SSH is port 22

They seem to always leave off port 20 is also ftp.

It’s just a data channel. This changed with nat and the introduction of the PASV command which allowed the client to set a non-well known port for the data channel

> the introduction of the PASV command which allowed the client to set a non-well known port for the data channel

PASV instructs the server to specify another ip:port that it’s listening on to enable the client to connect.

PORT expects there to be an open port on the client for the server to connect to.

That's exactly what TFA says?

this WKS field in DNS that it refers to isn't something I've heard about

Why isn't it used?

https://datatracker.ietf.org/doc/html/rfc1123#page-14

The WKS record type was, at one point, a record listing all network services available on a host. It consisted of a bitmap where each bit represented a port number, counting from 0 (!), where a bit being set indicated that the host offered a service on that port. This scheme only worked for low port numbers; it also inappropriately conflated DNS names with hosts. (The latter was perhaps a reasonable assumption when WKS was created sometime in the '70s or '80s, but it certainly isn't anymore.)

The most definitive references to WKS are probably:

* RFC 1035 (1987), which defines the record format.

* RFC 1912 (1996), which noted that "[WKS records] serve no known useful function, except internally among LISP machines. Don't use them."

You can do a lot better now with SRV records.

In 1995 everybody sending email was trustworthy. Those were the days...

Edit: Except if their address was @aol.com. Eternal September started in 1993.

I have a shirt that says "The Internet is full: Go Away!"

I will pay you 5 cents to print 15 of those t-shirts, with my company logo on it and a QR code that points to an article about an internet standard and why my crypto startup is better than it. 10 cents, final offer.

I wonder if IANA still assign numbers? Can I have them assign ports for, say, redis?

Yes, they do. Their mission hasn’t changed since IANAs inception.

But getting a port assignment these days is going to be virtually impossible. It’s probably not going to happen without at least a Proposed Standard RFC.

https://www.iana.org/assignments/service-names-port-numbers/...

There’s not a single RFC published that concerns redis. It’s not going to happen.

I got a port assigned a few years ago.

I needed to write a justification why the organisation I represented needs a port number (a custom binary protocol), a formal confirmation that protocol has versioning built-in (so we will not request for a new port number for the next version of the protocol), a confirmation that we have a running code implementing the protocol (if I recall correctly, link to documentation was sufficient), and the reasons why we cannot use any of the existing protocols.

It’s not impossible and I think it’s totally doable for redis unless the port is already reserved for something else.

Probably for the best.

If there was a moderately complicated bureaucratic process to be assured of getting one, it wouldn't be Redis or the next SSH that got assigned ports. It would be Oracle or HP or someone else incapable of pretending to be a good Internet citizen, who filled in 10,000 of the forms promising that they have 10,000 totally necessary well known enterprise services.

Someone should steal 666 TCP/UDP, no RFC and contact email is of a person who leaved id in 1996.

They could if redis went the way of proposing a RFC for their protocol. But I don't think it would be a good idea. But, if instead someone came up with a RFC proposing a standard protocol for communications with generic key-value stores like redis, it would make a lot more sense.

You shouldn’t need a hardcoded port number for a newly designed protocol. Register a service name instead, and use SRV or SVCB records in the DNS (and/or ZeroConf).

You’ll notice that on the official IANA list of port numbers and service names, there is a separate section, after the numbered ports, listing only service names¹. Just apply for one of those.

1. At the time of writing, starting on page 135 of the HTML version: <https://www.iana.org/assignments/service-names-port-numbers/...>

SSH is the most fantastic piece of black magic. So many incredible things are easy and secure.

Port forwarding

Reverse port forwarding

Rsync

So much more. And it's free. What a privilege to be alive today - I remember when all this was just a dream.

The headline of the article does not match the posting, which breaks a rule I believe. Could we at least correct the posting's grammar? To "How SSH became Port 22".

reminds me of the days when s/keys over telnet were cool.

there should be a vh1 where are they now special for assigned ports in /etc/services that shipped with early slackware.

I like how he didn’t explicitly request 22. It was more like “anything 1-255 would be great... oh, by the way, I happen to be using 22...”

He did request it:

> It would be great if this number could be used

ssh also used to use source port 22. At least a popular implementation of it did. A bit of websearching didn't find it; anyone else remember this?

Wouldn't that have meant you couldn't ssh out of a machine running an ssh server since the port was already bound to another process?

This is a good example of make it easy for others to say yes.

Reply on news.ycombinator.com