> 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.
> 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.
> 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.
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.
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.)
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.
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.
"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 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.
~/.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.
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.
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.
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!
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.
> 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.
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.
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).
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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?
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.
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.
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.
It's what John Gilmore said and claimed to believe (emphatically, unambiguously, repeatedly) to me in person that I object to, and the intellectually dishonest and factually incorrect way he argued in support of it, but not anything he's written publically, nor who he listens to.
He's been claiming to me and other people that I got mad that he listened to somebody I disagree with, but he's gaslighting about the point I clearly explained to him: I listened to what Scott Adams said too, so I know what he said, and what he's said in the past, and I don't agree with him, and I explained clearly why he was lying and wrong. But John made it extremely clear that he does believe Scott Adams' lies, and other White Supremacist propaganda, and he also spouts ridiculous climate change conspiracy theories.
It's not just because John Gilmore strongly AGREES with Scott Adams, but also that he intellectually dishonestly and emphatically argues in support of White Supremacist propaganda like "Black people are a hate group", and that "White people should stay the hell away from Black people" and "It's OK to be White", and believes he (a successful straight white multimillionaire) suffers from systemic reverse discrimination.
All that in spite of all my arguments and the evidence that I gave him, which he refused to listen to or look at. I'm sure he knows very well what the evidence says, because he's not as ignorant as he's pretending to be, and I certainly tried very hard to explain it to him, he just would not listen to me, and refuses to accept it.
John pretended not to know about Scott Adam's long sordid history, but when he mentioned his girlfriend was coming over, I offered to read some Scott Adams quotes to her so we could hear her opinion, and he got mad and slammed a door in my face and refused to talk with me for the rest of the night. Not the behavior of somebody on the winning side of an argument, or a mature adult arguing in good faith.
“The reality is that women are treated differently by society for exactly the same reason that children and the mentally handicapped are treated differently. It’s just easier this way for everyone. You don’t argue with a four-year old about why he shouldn’t eat candy for dinner. You don’t punch a mentally handicapped guy even if he punches you first. And you don’t argue when a women tells you she’s only making 80 cents to your dollar. It’s the path of least resistance. You save your energy for more important battles.” -Scott Adams
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.
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.
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.
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?
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.
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)
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.
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.
That is Don Hopkins, “a very imaginative fellow” (according to Richard Stallman), hacker extraordinaire, and very active in (and leader of many) important and well-known software projects throughout the 1990’s, or thereabouts. Here on HN, he often comments with insightful historical context (in his inimitable style). Just don’t get on his bad side, is all I’m saying (at this time); I have personal experience, but you can simply peruse his comment history here.
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.
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’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.
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).
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]
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"
> 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.
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 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."
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.
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.
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.
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.
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.
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.
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".
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>