Is port 22 (SSH) exposed to the internet, and does that matter?

Why a reachable SSH port draws attention

SSH (Secure Shell) is the standard way to administer Linux servers, network gear and a growing number of embedded devices remotely, and the protocol itself is sound: sessions are encrypted end to end and support both password and public-key authentication. The risk this page is about is narrower than “SSH is insecure” — it’s that port 22 is also one of the most continuously scanned ports on the public internet, precisely because it’s so common. CISA’s ICS-ALERT-12-034-01 describes the pattern directly: attackers “probe a large number of IPs” on port 22, and once a service answers, they move straight into a brute-force attempt — guessing usernames and passwords, sometimes with “hundreds or thousands of login attempts over a relatively short time period,” sometimes more slowly with “only a few careful attempts, then waiting to try again later” to stay under the radar of simple rate-limit detection.

The defaults are more permissive than many admins assume

Two settings decide how much that exposure actually matters, and both ship more open than it’s reasonable to assume. Per OpenBSD’s own sshd_config manual, PasswordAuthentication defaults to yes — password login is accepted unless an administrator turns it off — and PermitRootLogin defaults to prohibit-password, which still allows the root account to log in directly over SSH using a key, just not a password. Neither default disables the risk CISA describes; they only narrow it. A server that has never had its sshd_config touched is, by the distribution’s own default, still willing to accept password guesses against any account that exists on it, including root on older or differently-packaged systems.

How to check your own exposure

AdminKit’s open ports check tests whether port 22 on your own public IP responds from outside your network, with your consent and only against the IP making the request — confirm your current public IP first with what is my IP. A port that answers doesn’t automatically mean you’re compromised, but it does mean you’re part of the population CISA’s advisory describes as drawing continuous scanning traffic, and it’s worth knowing that before an incident, not after one.

How to fix it

• Set PasswordAuthentication no in sshd_config and switch every account to key-based authentication, which removes the credential-guessing attack CISA’s advisory describes entirely.
• Set PermitRootLogin no rather than relying on the prohibit-password default, and use a named account with sudo for administrative access instead.
• Put SSH behind a VPN, bastion host or an access broker so the login prompt itself isn’t reachable from the open internet, or at minimum restrict the port to known source IP ranges with a firewall rule.
• Consider CISA’s suggestion of moving SSH off port 22 to a non-standard port — a weak deterrent against a targeted attacker, but it does reduce the baseline scanning noise the advisory describes, which can make real attack attempts easier to spot in logs.
• Turn on fail2ban or an equivalent intrusion-prevention tool so repeated failed logins from one source trigger a temporary ban, directly addressing the “hundreds or thousands of login attempts” pattern CISA’s advisory flags as the clearest brute-force signal.

None of these steps require replacing SSH — they’re configuration and network-placement changes on top of a protocol that’s already sound, aimed specifically at the gap between “SSH is encrypted” and “this login prompt shouldn’t be reachable by anyone on the internet who wants to try.”

This is the same direct-exposure pattern this site covers for RDP on port 3389: a legitimate remote-access protocol that only becomes a real risk once its login prompt is reachable from anywhere on the internet rather than from a controlled network.

Defensive use only

Every check this page links to is for assets you own or are explicitly authorized to test. Never scan, probe, or attempt to connect to a network or device you don’t control — AdminKit’s active checks only ever run against the IP making the request or an asset you’ve verified ownership of. See our Disclaimer and Acceptable Use Policy for the full terms.

This guide is general information, not a security audit of your specific network — see our disclaimer for what AdminKit's guidance does and does not commit to.