Why ports became "doors" to the server, and who decided that SSH will be 22

When ports could only listen

In the early 1970s, ARPANET was in its infancy, TCP did not yet exist, and the only data transfer protocol was the unidirectional Network Control Protocol (NCP). But for full-fledged data exchange, two connections were needed—one there and one back—so engineers divided the numbers into odd for outgoing traffic and even for incoming.

As a result, Telnet got 1, FTP got 3, Echo got 7, and Discard got 9. All key services were on odd numbers because even ones became mirror halves for the reverse channel. Homosocketality in the direct sense was prohibited at the protocol level.

Moreover, at that time there were only 256 ports, and everyone then thought that this would be enough forever.

By the way, port 0 technically exists, but in the TCP header it means dynamic assignment, and in Berkeley sockets sin_port = 0 in bind() tells the kernel to choose by itself.

Jon Postel and the book of all numbers

In May 1972, a UCLA graduate student named Jon Postel wrote RFC 349 — a document whose consequences are comparable to the invention of the wheel. He proposed to appoint a "czar" who would issue official socket numbers and maintain the list, and gently hinted that he could be that "czar". By the way, "czar" is not my artistic creation; it was written so seriously in the document (it is below).

Thus Postel became the "czar of the Internet". He edited RFCs 791, 792, 793 (IP, ICMP, and TCP), and also maintained Assigned Numbers — a periodically updated document that was more important to network engineers of that time than the phone book.

When Tim Berners-Lee wrote in January 1992 that he wanted HTTP on port 80, Postel approved his request on the same day. In the source code of the world's first web browser, there is still a comment that the port was allocated by Jon Postel on January 24, 1992.

Postel worked according to the principle later named the Robustness Principle — "Be conservative in what you send, and liberal in what you accept." This, in his opinion, applied to both protocols and people. He allocated ports quickly, without bureaucracy, almost via a single email, because he understood that the Internet is growing, and its growth cannot be hindered.

Bill Joy and Berkeley Sockets

Around the same time in Berkeley (an undesirable organization in the Russian Federation), American programmer Bill Joy was working on version 4.2 of the BSD operating system. To speed up development, DARPA, which was funding the project, commissioned the company BBN to write the TCP/IP stack. However, their code barely managed 50 Kbps, so Joy rewrote everything himself.

When BBN sent a new official version, Joy refused to accept it, since Berkeley already had a stack that flew at 3 Mbps. Later, at a meeting, he said it was all very simple—you read the protocol and write the code.

In 4.2 BSD, released in August 1983, the Berkeley sockets API appeared: socket(), bind(), listen(), and accept(). Joy integrated sockets with Unix file descriptors, and a socket became a file, a port became its address, and the system call became the handle to that very "door" of the port.

Time passed, and on January 1, 1983, ARPANET shut down NCP and switched to TCP/IP. The new protocol was bidirectional, so even ports almost instantly lost their meaning. 2, 4, 6, 8, 10, 12, and so on down the list remained reserved but never used slots.

Now the "infinite" became the sixteen bits of address space, that is, 65,536 ports. However, today even this range periodically runs out on quite ordinary servers.

How to get a port in one day

Even after the transition to TCP/IP, Telnet transmitted passwords in plain text, rlogin trusted virtually all IP addresses, and FTP required a separate channel that firewalls were happy to drop. A new protocol was needed... And so, in the spring of 1995, Finnish researcher Tatu Ylönen finished his program for secure remote access — Secure Shell, commonly known as SSH. This protocol needed a port.

On July 10, 1995, at 11:45 Helsinki time, Ylönen sent an email to IANA. In it, he wrote that he had developed a program for secure remote login over untrusted networks. Ylönen noted that he planned to distribute SSH for free and requested a registered privileged port for it, preferably in the 1–255 range, so the service could be correctly specified in WKS DNS records.

Additionally, the message noted that during beta testing, SSH was already using port 22, which at that time was listed as "unassigned," and the developer asked to assign specifically that one.

On the same day, at 15:35 Pacific Time, he received a reply from Joyce K. Reynolds of IANA:

Ylönen's small letter helped to formally assign port 22 to SSH.

How Ports Became the Mask

IPv4 addresses ran out faster than engineers anticipated, necessitating a new solution. It was found in 1994 when the IETF working group released RFC 1631, describing NAT — a mechanism in TCP/IP networks that allows transforming the IP addresses of transit packets. From that point on, the port ceased to be merely a service address inside a machine; it also became an identifier for a specific client behind the router.

Two years later, in 1996, PAT technology emerged. The router began rewriting the source port in outgoing connections, and hundreds of devices in an office could work simultaneously through a single external address.

This worked so well that the Internet essentially abandoned the end-to-end principle, as a node behind NAT became unreachable from the outside without a pre-created forwarding rule.

Containers added another layer. For example, host port 8080 is proxied to internal port 80 in the container, but the kernel still contains the same hash tables, the same tcp_v4_rcv(), and still the same 16 bits. That is precisely why ports remain "doors" to this day.

When "door locks" are checked

If a port is a "door," sooner or later someone will start knocking on all of them. Thus, in September 1996, the PANIX provider from New York discovered that its mail servers stopped responding because someone was sending a stream of SYN packets, filling the queue of half-open connections. This was one of the first SYN flood attacks, which drew CERT's attention.

After this attack, a group of network experts released a bulletin recommending filtering spoofed traffic, but a protection mechanism did not exist at that time, and no one knew how to do it. The problem was with TCP itself - the server allocated resources for each incoming SYN connection even before the handshake was completed. This is what allowed SYN attacks to quickly fill up the queue of half-open connections.

However, the solution did not take long to emerge. A week after the attack on PANIX, Daniel Bernstein and Eric Schenk proposed the SYN cookies mechanism. According to it, instead of allocating memory and creating a record of a half-open connection for each SYN packet, the server encoded the connection parameters in the TCP sequence number and sent the client a SYN-ACK without saving the state.

If the client was legitimate, it responded with a correct ACK, after which the kernel restored the connection state. If the SYN was spoofed or sent by a bot, the response did not come, and the server did not waste resources.

A year later, in 1997, Gordon Lyon under the pseudonym Fyodor Vaskovich (a reference to Dostoevsky) released Nmap - a tool that automated network reconnaissance. This scanner sent packets to different ports and determined which services were available from the outside based on the responses.

Later, Nmap learned to identify operating systems by the peculiarities of the TCP/IP stack, recognize service versions by banners and signatures, as well as bypass some filtering through non-standard scanning techniques and packet fragmentation.

By the way, in "The Matrix Reloaded," Trinity uses Nmap, finds an open SSH on port 22 of a SCADA system, and connects to it—this is one of the few technically plausible moments in Hollywood cinema.

Even then, it was clear to everyone that an open port is a potential attack point, so system administrators began mass-migrating SSH from port 22 to non-standard ones, reducing the flow of automatic scans and brute-force attempts.

However, there are nuances here too. For example, if you move SSH to port 2222 (registered for Ethernet/IP-1), the service will end up in the registered ports range 1024–49151, where some numbers are already assigned to other protocols. Usually, this doesn't cause problems, but in corporate networks, collisions and questions from security teams are possible.

What Will Remain of the "Doors"

Every infrastructure abstraction that engineers consider eternal eventually turns into an implementation detail. IP addresses are hidden behind DNS, disks behind volume managers, and ports are gradually dissolving into service discovery, mesh networks, and serverless architectures. But even now, when something breaks, a sysadmin opens a terminal and types `ssh -p 22` or `netstat -tlnp` to check who's occupying port 80, or `nmap -p-` to make sure the previous admin didn't leave any open doors.

Ports have survived NCP, TCP/IP, and NAT, because they are brilliantly simple — 16 bits, 65,536 values, and all the complexity of the internet fits into this number. I think they will continue to live on for decades to come…

How many ports are open on your server right now? Share in the comments, it will be interesting to compare.

© 2026 MT FINANCE LLC