SSH Misconfiguration (Port 22)
detect, fix, and prevent regression

Cloud security group rule too broad

An AWS security group, Azure NSG, or GCP firewall rule opens TCP 22 to 0.0.0.0/0 during a Terraform run, a debug session, a vendor handoff, or a recovery exercise. The rule is never narrowed, and a public SSH listener persists across image rebuilds, autoscaling events, and account migrations.

Password authentication and root login left on

PasswordAuthentication remains yes and PermitRootLogin remains yes (or the more permissive prohibit-password is set on an image that still ships a password-using root account). Brute-force protection sits at the network layer or in fail2ban only, not at the protocol layer through key-only enforcement.

Legacy ciphers, MACs, and KEX in use

sshd_config still advertises hmac-md5, hmac-sha1, arcfour, blowfish, 3des-cbc, diffie-hellman-group1-sha1, or diffie-hellman-group14-sha1 because removing them broke a legacy client years ago. SSH protocol 1 may even remain enabled on archaic builds. The current ssh-audit and NCSC guidance treat the legacy set as a finding by default.

Aged or unpatched OpenSSH and Dropbear builds

Long-lived virtual machines, containers built from frozen base images, IoT firmware, OT switches, network appliances, and home-grown CI agents run an OpenSSH or Dropbear release several years behind the upstream support window. regreSSHion (CVE-2024-6387) and Terrapin (CVE-2023-48795) are recent examples that turn aged builds into immediate exposure events.

Agent, X11, and TCP forwarding left default

AllowAgentForwarding yes, X11Forwarding yes, and AllowTcpForwarding yes are inherited from a stock distro config. An attacker who lands a single session can hop to internal hosts through the developer's forwarded agent, tunnel deeper through the SSH connection, or read X11 windows on the originating workstation.

Host key reuse and missing rotation

Cloned virtual machines and container base images share the same SSH host key, breaking the host-key trust model and enabling man-in-the-middle attacks across the fleet. Host keys are never rotated after suspected compromise or key-material exposure through accidental backup, snapshot, or repository commit.

Automated detection

• SecPortal's external scanner port-scan module probes TCP 22 across every verified domain and host in scope, captures the SSH banner (OpenSSH or Dropbear with version where the host advertises it), and raises a finding with the recommendation to restrict source IPs, disable password authentication, and patch the build.
• Continuous monitoring re-runs the external scan on a schedule, so a security-group edit, a Terraform apply, an autoscale event, or a recovered host that re-exposes 22 reopens the finding rather than leaving the regression invisible until the next manual review or audit cycle.
• Bulk import accepts Nessus, Burp, and CSV output from network-tier scanners and from ssh-audit or sslyze runs that already report weak ciphers, legacy KEX, vulnerable OpenSSH versions, and missing key-only enforcement, so the catalogue stays centralised even when a third-party tool is the original discovery source.

Manual verification

• Use nmap -p 22 with service detection (-sV) and the ssh2-enum-algos and ssh-hostkey scripts against the external range to confirm the listener, the OpenSSH or Dropbear build, the offered KEX and cipher and MAC sets, and the host key set advertised on each port.
• Run ssh-audit against each reachable listener to read the policy summary (acceptable, deprecated, weak), check whether the host accepts known-weak algorithms, and produce a per-host hardening recommendation that mirrors the upstream Mozilla and NCSC guidance.
• Cross-reference the OpenSSH version banner against the CISA Known Exploited Vulnerabilities catalog, the OpenSSH security advisory page, and the vendor advisory feed to identify whether regreSSHion (CVE-2024-6387), Terrapin (CVE-2023-48795), or any other unpatched SSH CVE is present.
• Check Shodan and Censys for the organisation's netblocks and known hostnames to see whether external observatories already list exposed SSH services and the banners they advertise, then reconcile that list against the verified-domain inventory inside the workspace.

Surface every listener on one finding record

External scanning and bulk import land every exposed-SSH detection on the findings management record with CVSS, the discovered host, the captured banner, the scan timestamp, and the named owner so the catalogue is a single source of truth rather than a Shodan tab, a spreadsheet, and a Slack thread.

Capture configuration drift through authenticated scans

Where the team already has authorisation, the authenticated scanning path reads the responding service in more detail and pairs the result with the per-host hardening record. Credentials for authenticated runs live in encrypted credential storage scoped to a verified domain so the same secret is not copied across spreadsheets and chat threads.

Run remediation as a tracked workflow

Each finding flows through the remediation tracking workflow with severity, target close date, named owner, and the agreed compensating control (for example, an inbound source allowlist while the bastion migration completes, or a temporary fail2ban rule while a certificate authority is stood up). Permanent exceptions enter the eight-field exception register with a named approver, a rationale, an effective period, and a renewal cadence.

Verify the fix with retest

Once the firewall rule, security-group edit, sshd_config change, host retirement, or bastion migration completes, the retesting workflow re-runs the external scan, confirms the listener is gone or that the banner now advertises a patched build with the modern algorithm set, and stamps the closure with timestamped evidence rather than a verbal sign-off.

Catch regressions through continuous monitoring

Scheduled continuous monitoring re-scans of verified domains reopen the finding if SSH returns to the public internet, if the banner drops back to a vulnerable build, or if a new cloud account joins the estate with an open 22. A Terraform apply, an autoscaler refresh, or a recovered backup image does not silently reintroduce the exposure.

Pair with the broader exposure catalogue

Exposed SSH rarely shows up alone. The same host frequently exposes exposed RDP, exposed SMB, default credentials, or TLS or SSL misconfiguration. On the data-service side of the same host, an exposed MongoDB listener or an exposed Elasticsearch cluster is the most common companion finding. On the container-runtime side of the same host, an exposed Docker socket on TCP 2375 or a mounted /var/run/docker.sock inside a CI runner gives an attacker who already has the SSH foothold root-equivalent control of every container on the host. Treating SSH exposure as one finding inside a host-level posture review keeps the queue ordered against real residual risk rather than chasing isolated ports one at a time.

Carry the audit trail through closure

The activity log records who opened, scoped, remediated, and verified each SSH-misconfiguration finding, so the next ISO 27001, SOC 2, PCI DSS, CIS Benchmark review, or cyber insurance renewal reads the operating evidence from the record rather than from reconstructed memory, archived ticket exports, or screenshots taken weeks after the fact.

Communicate posture in leadership language

When SSH posture sits inside a broader programme review, the Claude-drafted AI report composes a leadership-ready narrative from the open and closed findings, the remediation cadence, and the linked compliance evidence. The same record drives security leadership reporting without rebuilding the slide deck by hand each quarter.

Cloud workloads and bastion hosts

Bastion hosts, jump servers, ad-hoc EC2 and Compute Engine instances, and short-lived debug hosts make up the bulk of cloud SSH exposure. Replace standing 0.0.0.0/0 rules with managed bastion services, identity-aware proxies, or zero-trust access brokers. Use short-lived SSH certificates instead of long-lived authorized_keys files. Pair the workspace with the cloud-security review described in /use-cases/cloud-security-assessment.

Network appliances and OT devices

Switches, routers, load balancers, firewalls, NAS appliances, and OT control gateways ship with SSH on by default and frequently with vendor default credentials. Coordinate the hardening with the appliance vendor, capture the firmware build on the finding, and confirm the closure against the cleared CISA KEV catalogue entry where applicable.

IoT and consumer-grade Linux

Long-lived IoT firmware, home-grown Linux builds, and developer-built CI runners frequently ship Dropbear SSH with weak defaults, legacy ciphers, and unpatched libraries. Track these hosts on the finding record with the firmware identifier, the maintainer contact, and the upgrade path. Where the device cannot be patched, isolate it behind a managed network access boundary and document the residual risk decision in the exception register.

Git over SSH and CI runners

SSH is the trust boundary for source-code repository access and for self-hosted runner registration. Compromise of a developer key, a runner identity, or an unrotated deploy key reaches the source code, the deployment pipeline, and the secret store. Pair SSH posture with the developer-workstation key inventory, the platform-side key audit, and the runner rotation cadence so the workspace covers the human, the runner, and the host.