Port 22 – SSH (Secure Shell)

Port 22 is the default port for SSH (Secure Shell), the protocol that gives you an encrypted remote shell, file transfer over SFTP and SCP, and port forwarding through a single connection. The SSH daemon — almost always OpenSSH’s sshd on Linux and BSD, or Dropbear on embedded gear — listens here and authenticates clients by password or public key before opening a session. Unlike Telnet on port 23, everything after the initial handshake is encrypted, so port 22 is rarely the weak link itself — the credentials and keys behind it usually are.

Why It’s Open

SSH is how servers get administered, so you’ll find port 22 open on basically anything you can log into: cloud instances, bare-metal boxes, routers and switches, NAS appliances, hypervisors, CI runners, and the millions of IoT and home devices running Dropbear. It also carries a lot of traffic that isn’t an interactive shell — Git over SSH, Ansible and other config-management tools, rsync, SFTP jobs, and tunnels that forward database or admin ports through an encrypted pipe. When FTP on port 21 gets retired, SFTP riding on port 22 is usually what replaces it, which is why the two often show up together on the same host.

Common Risks

• Password brute-forcing. Internet-facing port 22 gets hit by automated password guessing constantly. Weak or reused credentials, and vendor defaults on appliances (root:root, admin:admin), fall fast.
• Exposed root login. PermitRootLogin yes with password auth turns one guessed password into a root shell. Older distros shipped this on by default.
• Key management gone wrong. Orphaned authorized_keys entries, private keys committed to repos or left world-readable, and keys with no passphrase all bypass your password policy entirely.
• Outdated OpenSSH. Old daemons carry real bugs — the 2024 regreSSHion flaw (CVE-2024-6387) is unauthenticated root RCE, and username-enumeration and agent-forwarding issues affect a range of versions.
• Weak or downgradable crypto. Legacy ciphers (CBC, arcfour), SSHv1 support, and the algorithms targeted by the Terrapin attack let an on-path attacker weaken or fingerprint the session.
• Agent and tunnel abuse. Forwarded SSH agents (ForwardAgent yes) let whoever controls the jump host reuse your keys; permissive tunneling can turn a single foothold into a pivot deeper into the network.

Want to save time on reporting?

Let PentestPad generate, track, and export your reports - automatically.

Book a Demo

Enumeration & Testing

Detect the service and grab the host keys

nmap -sV -p 22 --script=ssh2-enum-algos,ssh-hostkey,ssh-auth-methods <target>

Raw banner grab with netcat

The banner reveals the OpenSSH (or Dropbear) version, which is your first cross-reference against known CVEs.

nc -nv <target> 22

Connect with the native client

ssh user@<target>

Use -v to watch the key exchange and see which auth methods the server offers:

ssh -v user@<target>

Audit the crypto with ssh-audit

ssh-audit <target>

This flags weak ciphers, MACs, key-exchange algorithms, SSHv1 support, and known issues like Terrapin in one pass.

Enumerate valid usernames (CVE-2018-15473)

msfconsole -q
use auxiliary/scanner/ssh/ssh_enumusers
set RHOSTS <target>
set USER_FILE users.txt
run

Brute-force with Hydra

hydra -L users.txt -P passwords.txt ssh://<target> -t 4 -f

Metasploit login scanner

msfconsole -q
use auxiliary/scanner/ssh/ssh_version
set RHOSTS <target>
run

use auxiliary/scanner/ssh/ssh_login
set RHOSTS <target>
set USER_FILE users.txt
set PASS_FILE passwords.txt
set STOP_ON_SUCCESS true
run

Keep a record of every host with password auth enabled, every default login that works, and every weak-crypto finding so it lands in the final pentest report rather than a scratch file.

What to Look For

Known CVEs and Exploits

• CVE-2024-6387 — “regreSSHion.” A signal-handler race condition in OpenSSH sshd on glibc-based Linux gives unauthenticated remote code execution as root. It hits OpenSSH 8.5p1 through 9.7p1 (and very old builds before 4.4p1), and is a regression of the long-fixed CVE-2006-5051. Exploitation is slow and non-deterministic because it’s a race, but it’s pre-auth root, so patch it before anything else.
• CVE-2023-48795 — The Terrapin attack. A prefix-truncation flaw in the SSH transport protocol lets an on-path attacker silently delete messages during the handshake, downgrading security features. It affects the widely used ChaCha20-Poly1305 and CBC-EtM modes; the fix is the strict-kex countermeasure in modern clients and servers.
• CVE-2023-38408 — Remote code execution through the PKCS#11 feature of ssh-agent. If a forwarded agent reaches an attacker-controlled host and certain libraries sit in the default path, the attacker can run code on the machine that forwarded the agent. Fixed in OpenSSH 9.3p2.
• CVE-2018-15473 — Username enumeration. Pre-7.7 OpenSSH responds differently to malformed authentication requests for valid versus invalid users, letting an attacker build a list of real accounts before brute-forcing. Public PoCs and the Metasploit ssh_enumusers module both automate it.
• CVE-2020-15778 — Command injection in scp via crafted filenames containing backtick or shell metacharacters. It’s the main reason OpenSSH now steers users toward SFTP and deprecated the legacy scp protocol.

Mitigation

• Disable password auth. Set PasswordAuthentication no and PubkeyAuthentication yes, and use SSH keys — ideally hardware-backed or passphrase-protected — everywhere.
• Disable root login. PermitRootLogin no, then use a normal account plus sudo.
• Patch OpenSSH. Keep the daemon current so regreSSHion, the agent-forwarding RCE, and the enumeration bug are all closed; don’t forget Dropbear on appliances.
• Restrict who and where. Limit accounts with AllowUsers/AllowGroups, firewall port 22 to a management range or VPN, and consider a non-standard port only as noise reduction — it’s not a security control on its own.
• Harden the crypto. Drop CBC ciphers, arcfour, and SSHv1; confirm strict-kex support to close Terrapin; audit the config with ssh-audit after any change.
• Add a second factor and rate limiting. Enforce MFA (e.g. via PAM) for interactive logins and put fail2ban or MaxAuthTries/MaxStartups limits on repeated failures.

Real-World Example

On 1 July 2024 Qualys disclosed regreSSHion (CVE-2024-6387), an unauthenticated remote root code-execution bug in OpenSSH’s server. What made it notable wasn’t just severity but reach: OpenSSH is the default remote-access daemon on almost every Linux server, and Qualys estimated over 14 million internet-facing instances were potentially affected. The flaw was a race condition in the SIGALRM handler — async-signal-unsafe code that had been fixed back in 2006 (CVE-2006-5051) and quietly reintroduced in 2020. It’s a clean reminder that port 22 being encrypted says nothing about whether the daemon behind it is safe: the exposure was in the code answering the connection, not the protocol.

FAQ

What service runs on port 22?

SSH (Secure Shell). Port 22 is the registered default for the SSH daemon, which provides encrypted remote login, file transfer via SFTP and SCP, and tunneling. On most systems that daemon is OpenSSH’s sshd; embedded devices often run Dropbear instead.

Is port 22 dangerous to leave open?

Port 22 itself is encrypted, so it’s much safer than plaintext alternatives like Telnet. The risk is what’s behind it: weak passwords, exposed root login, unpatched OpenSSH versions, and mismanaged keys. An internet-facing port 22 will be brute-forced continuously, so lock it down with key-only auth, no root login, and a firewall rule limiting who can reach it.

Can I change the SSH port from 22?

Yes — set Port <number> in sshd_config and restart the daemon. Moving off 22 cuts down automated scan noise, but treat it as convenience, not security: a real attacker finds the new port in one scan. Keep key-based auth and patching as your actual defenses.

How do I check whether port 22 is open?

From another host, run nmap -p 22 <target> or nc -nv <target> 22 to see if it’s listening and grab the version banner. Locally, ss -tlnp | grep :22 shows whether sshd is bound and to which interfaces.

TL;DR

• Service: SSH (Secure Shell) — encrypted remote login, SFTP/SCP, and tunneling
• Default port: 22/TCP
• Biggest risk: brute-forceable passwords, exposed root login, and unpatched OpenSSH (e.g. regreSSHion, CVE-2024-6387)
• Mitigation: key-only auth, PermitRootLogin no, patch the daemon, firewall to a management range