22 SSH TCP Flagship

What it's for

Port 22 is the default port for SSH (Secure Shell) — the protocol almost every server on the internet uses for remote command-line access. When you run ssh user@host, your client is opening a TCP connection to port 22 on that host, negotiating an encrypted channel, and authenticating you (usually via a password or, better, a public key).

SSH replaced Telnet (port 23) specifically because Telnet sends everything — including your password — in plaintext. Every byte over an SSH connection is encrypted, which is why port 22 is one of the few "old" ports that's still the unambiguous right answer today rather than a legacy holdover.

Beyond interactive shells, port 22 also carries SCP and SFTP (secure file transfer), Git-over-SSH (git clone [email protected]:...), and tunneling — a single SSH connection can forward arbitrary TCP traffic through an encrypted pipe, which is why it shows up constantly in "how do I access my database through a bastion host" setups.

Protocol basics

• Protocol: TCP. SSH needs a reliable, ordered byte stream since it's carrying a full terminal session or file transfer — UDP's unordered/lossy delivery model doesn't fit.
• Handshake: client and server first agree on a protocol version and negotiate encryption algorithms, then perform a key exchange (commonly Diffie-Hellman variants) to establish a shared session key before any authentication happens.
• Authentication methods: password, public key (the recommended default for anything internet-facing), keyboard-interactive (used for MFA prompts), and occasionally host-based auth in tightly controlled internal networks.
• Persistent connections: a single SSH session commonly stays open for a whole working session, and connections can multiplex several channels (a shell, port forwards, SFTP) over one TCP socket.

Security considerations

Port 22 is one of the most-scanned ports on the entire internet — any server with SSH exposed to the public internet will see automated login attempts within minutes of going live. That's expected and mostly harmless if your configuration is solid, but it's worth locking down deliberately:

• Disable password authentication and require public-key auth. This alone kills the vast majority of brute-force attempts, since guessing a private key is computationally infeasible.
• Disable root login (PermitRootLogin no) — force administrators to log in as a normal user and sudo from there, which also gives you an audit trail.
• Consider moving off port 22 for internet-facing hosts. This doesn't add real cryptographic security, but it does dramatically cut down log noise from opportunistic scanners — "security through obscurity" as a noise filter, not a real control.
• Use fail2ban or equivalent to automatically block IPs after repeated failed attempts.
• Keep SSH server software patched. Vulnerabilities in OpenSSH are rare but high-severity when they happen, since they can grant remote code execution.
• Use a bastion/jump host for cloud infrastructure rather than exposing port 22 on every individual instance — one hardened, monitored entry point instead of dozens.

Troubleshooting

Connection refused:

• SSH daemon (sshd) isn't running on the target host — check with systemctl status sshd
• A firewall (security group, ufw, iptables) is blocking port 22 inbound

Connection times out (hangs, no response):

• A network-level firewall or cloud security group is silently dropping the packets rather than rejecting them — check security group / NACL rules first
• Wrong IP address or the host is simply down

Permission denied (publickey):

• Your public key isn't in the server's ~/.ssh/authorized_keys for that user
• Wrong private key is being offered — use ssh -i /path/to/key to specify explicitly, or check ssh -v verbose output to see which keys are being tried
• File permissions on ~/.ssh or authorized_keys are too open — SSH refuses to use key files that aren't properly restricted (typically 700 for .ssh, 600 for the key files)

Host key verification failed:

• The server's host key changed (common after a server rebuild) — if expected, remove the old entry from ~/.ssh/known_hosts with ssh-keygen -R hostname

Comparison / FAQ

Is it safe to expose port 22 to the internet?

It can be, provided you disable password auth in favor of public-key authentication, disable root login, and keep the SSH daemon patched. Many teams additionally restrict access to a VPN or bastion host rather than opening it to 0.0.0.0/0.

Why do people move SSH to a non-standard port?

Mainly to reduce log noise from automated scanners constantly probing port 22. It doesn't add meaningful cryptographic security — a determined attacker can still find an SSH service on any port with a quick scan — but it does cut down the sheer volume of junk authentication attempts you have to filter through.

What's the difference between SSH and SFTP?

SFTP (SSH File Transfer Protocol) isn't a separate service — it's a subsystem that runs over an existing SSH connection on the same port 22. If SSH access works, SFTP works too, using the same authentication.

Can I run multiple SSH servers on different ports?

Yes — sshd_config supports a Port directive that can be specified multiple times to listen on several ports simultaneously, which some admins use to keep 22 open for convenience while also listening on a secondary port.