Ports

Port 22: SSH

Secure remote login and file transfer foundation. Commonly used for admin access.

Where you will see it: You will see this in scans, firewall rules, vulnerability reports, and service configs. Treat open ports as exposure points and verify the service is expected, hardened, and restricted.

What it is

TCP port 22 is the default port for SSH. A port is a transport layer number used together with an IP address and a protocol such as TCP or UDP to direct traffic to the correct service on a host.

A server process binds a socket to a port and listens, while a client typically chooses an ephemeral source port for outbound connections. The combination of source and destination IP addresses, source and destination ports, and the transport protocol uniquely identifies a flow so the operating system can keep many conversations separate.

Firewalls, NAT, and scanners talk about ports because the destination port is the stable rendezvous point that exposes a service to the network. An SSH server binds to port 22 and waits in a listening state.

When you connect, your client opens a TCP session from an ephemeral source port to the server IP and destination port 22, completes the TCP handshake, and then starts the SSH protocol on top of that connection. SSH negotiates encryption, authenticates the user or key, and then multiplexes one connection into channels for an interactive shell, single command execution, file transfer via SFTP, or port forwarding.

That is why scanning for 22 is a common way to find remote administration surfaces. If you understand ports, you can see why moving SSH to a different port reduces noise but does not remove risk: the service is still reachable, just at a different rendezvous point.

How it works in broad strokes

  1. Client connects and negotiates algorithms for key exchange, encryption, and integrity.
  2. The server proves its identity with a host key, then the user authenticates with a key or password.
  3. After authentication, SSH opens one or more channels for shells, commands, port forwarding, or SFTP.

Concrete example

A developer runs git operations against a server. Under the hood, an SSH session authenticates with a key, then the server opens a channel for the git command and returns the results over the encrypted stream.

Why it matters

SSH is one of the most security sensitive services in most environments. It is powerful by design, so an exposed or weakly protected SSH service is a common entry point. It also shows up everywhere in automation, backups, and server management.

Security angle

  • Prefer key based auth, disable weak ciphers, and restrict by network or VPN.
  • Use MFA or short lived certificates where possible, and log all auth events.
  • Treat SSH keys as secrets: protect them, rotate them, and remove access when people leave.

Common pitfalls

  • Allowing password auth from the internet without rate limiting.
  • Reusing keys across many systems or never rotating them.
  • Ignoring host key changes, which can hide man in the middle attacks or compromised hosts.