How SSH port became 22 (2017)

Original Article ↗ Hacker News Discussion ↗

SSH’s assignment to TCP port 22 becomes a jumping-off point for exploring how early internet port numbers were allocated, why common services cluster around “well-known” ports, and how conventions like IANA’s registry evolved. Commenters contrast the informal, low-friction process of the 1990s—with an email often being enough to reserve a port or obtain an object identifier—with today’s more formal requirements, and debate whether strict port assignments are still necessary in a world of SRV records and ubiquitous port 443. The thread also branches into related history: telnet/rsh vs. SSH, legacy mechanisms like WKS records, and the legal and political battles around strong cryptography that shaped tools like SSH and PGP.

Early Internet context and port 22

  • Commenters express nostalgia at how informal early Internet governance was (e.g., just emailing to get a port; DNS roots briefly repointed on request; NANOG on IRC).
  • Some feel “sad to have missed it”; others note that even then it involved a very small group, just like today’s early‑stage technologies.

Port conventions, standards, and discovery

  • Debate over whether “worldwide conventions” for ports exist:
    • One side: well‑known ports (e.g., 21/FTP, 22/SSH, 80/HTTP) are clearly standardized via IANA and widely relied upon.
    • Other side: there is no “Internet police”; conventions can be ignored, but you incur compatibility or operational risks.
  • Discussion of IANA’s current role:
    • Port assignment is still possible but harder, often expected to be tied to an RFC.
    • Alternatives recommended: use DNS SRV/SVCB records or service names without fixed ports.
  • People mention reference sources: IANA tables, Wikipedia’s list, /etc/services, nmap’s nmap-services, and even old router GUIs as informal “port encyclopedias.”

Historical protocols and port layout

  • WKS DNS records once advertised services as bitmaps of low-numbered ports; now considered obsolete and replaced effectively by SRV.
  • Explanation that early NCP used even/odd inbound/outbound pairs, influencing many old services to use odd ports; FTP’s use of 20/21 is cited as a surviving artifact.
  • Clarifications of FTP active/passive modes (PORT vs PASV) and how data channels moved away from well‑known ports.

Crypto wars, legality, and cypherpunks

  • Thread revisits 1990s export controls:
    • One view: “encryption/PGP was banned” or effectively chilled by export rules.
    • Counterview: use of strong crypto inside the US was legal; only export was regulated, mainly via paperwork and “US‑only” download warnings.
    • Several note the gap between de jure rules and de facto lax enforcement, especially for individuals.
  • Broader reflection on cypherpunk tactics:
    • “Write and release code to make laws unenforceable” is praised as effective but criticized as anti‑democratic (bypassing majority will).
    • Discussion touches on democratic paradoxes (e.g., when majorities might vote against encryption or even against democracy itself).

SSH’s relationship to earlier tools

  • Some insist SSH primarily replaced rsh/rlogin/rcp on Unix systems; others say their own experience was mostly telnet/FTP being replaced.
  • Telnet encryption options existed in RFCs, but SSH gained mindshare instead.

SSH usability and tooling

  • Repeated annoyance at ssh -p vs scp -P and scp’s argument ordering; people share workarounds (-o Port=, rsync, ~/.ssh/config).
  • Mentions of SSH “black magic” features: (reverse) port forwarding, rsync over SSH, etc., with general appreciation for how powerful and accessible it is.