SSH hardening is an identity problem, not a port problem

At a glance

What this is: This is an analysis of SSH hardening that argues port 22 is not the main security control, and that cryptography, forwarding, and access model matter more.

Why it matters: For IAM and NHI practitioners, it shows why SSH governance depends on credential lifecycle, session policy, and pre-auth controls rather than port changes alone.

👉 Read Teleport's SSH hardening guidance on ports, forwarding, and certificates

Context

SSH is a transport and access path, but its security posture is shaped by authentication, authorization, and session control rather than the port number alone. In NHI governance terms, SSH keys, certificates, and forwarding rules are all non-human identity controls because they grant software-mediated access with real operational blast radius.

The article focuses on production SSH hardening and why common advice misses the deeper control surface. That framing is typical for environments where SSH has been left to server admins instead of being folded into identity governance, certificate lifecycle management, and access review.

Port 22 is not a control plane: changing the listening port can reduce noise from opportunistic scanning, but it does not change who can authenticate, what algorithms are allowed, or what tunnels can be created after login.

Key questions

Q: How should security teams harden SSH without relying on port changes alone?

A: Teams should treat SSH as an identity and access problem. Change the port only if it reduces operational noise, then focus on authentication strength, forwarding restrictions, algorithm floors, and pre-auth rate limiting. The real security improvement comes from reducing trust in static credentials and making access time-bound, reviewable, and deliberately scoped.

Q: When does SSH forwarding create more risk than value?

A: SSH forwarding creates more risk than value when it is enabled by default but used for only a small set of admin tasks. In that case, it expands the attack surface, can bypass network controls, and may create unmonitored tunnels. Disable it unless a documented operational use case justifies the exposure.

Q: What is the difference between changing port 22 and real SSH hardening?

A: Changing port 22 mostly reduces background scanning noise. Real hardening changes the trust model by restricting algorithms, limiting authentication abuse, controlling forwarding, and shifting access to short-lived identity-bound credentials. One is a transport tweak, while the other reduces the chance that a valid session becomes an uncontrolled access path.

Q: Should organisations use SSH certificates instead of long-lived keys?

A: Yes, when they can support the operational model. SSH certificates reduce standing access, simplify revocation, and make expiration a built-in control rather than a manual cleanup task. That gives security teams a cleaner governance model for NHI access because the credential itself carries scope and lifetime limits.

Technical breakdown

Why changing SSH port 22 does not change the trust model

Port 22 is only the TCP entry point where the SSH handshake begins. Once the connection reaches sshd, the server applies key exchange settings, cipher policy, authentication rules, and session authorization from sshd_config. That means moving SSH to another port may reduce background scanning, but it does not alter the trust assumptions embedded in password login, permissive forwarding, or weak algorithm negotiation. The operational risk stays the same if the identity model stays the same. In NHI terms, the port is transport, while the credential and policy are the real control surface.

Practical implication: Treat port changes as hygiene, not hardening, and review authentication and authorization controls separately.

How SSH forwarding expands the attack surface

Local forwarding, remote forwarding, and dynamic forwarding each turn SSH into more than an interactive shell. Local forwarding can expose internal services through a client-side tunnel, remote forwarding can create reverse access paths back into a network, and dynamic forwarding can act as a SOCKS proxy for arbitrary traffic. This matters because the tunnel inherits the trust of the authenticated SSH session, so a compromise or misuse of that session can become a broader access path. GatewayPorts and permissive defaults increase the chance that a forwarding feature becomes an unintended NHI channel rather than a controlled admin tool.

Practical implication: Inventory where forwarding is actually needed and disable it everywhere else at the server policy layer.

Why algorithm floors and rate limits matter before authentication

SSH security also depends on what the server refuses to negotiate. Strong defaults only help if weak KexAlgorithms, ciphers, and MACs are removed so legacy clients cannot force weaker choices. On top of that, pre-auth controls such as connection rate limits and penalties reduce brute-force pressure before sshd spends resources on full authentication attempts. That pre-auth layer is important because repeated unauthenticated sessions are part of how internet-facing SSH services get exhausted or probed at scale. In practice, cryptographic policy and abuse throttling are complementary controls, not substitutes.

Practical implication: Set explicit algorithm baselines and pre-auth throttles before exposing SSH to the internet.

Threat narrative

Attacker objective: The attacker wants to turn a legitimate SSH session into a durable access path that bypasses network controls and increases blast radius.

1. Entry occurs through internet-wide scanning or a reachable forwarding path that exposes SSH to automated probing and tunneling abuse.
2. Escalation follows weak authentication, permissive forwarding, or legacy algorithm negotiation that allows the attacker to convert one session into broader access.
3. Impact is unauthorized lateral movement, proxying, or data exfiltration through a trusted SSH channel.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

SSH hardening has been oversold as a port problem, but the real issue is access governance. Moving off port 22 can reduce noise, yet it leaves the fundamental trust model unchanged. SSH still relies on credentials, server policy, and session-level authorization, which makes it an NHI governance problem rather than a networking tweak. Practitioners should stop treating the port as the control and start treating the session as the unit of risk.

Forwarding is the part of SSH that most often changes the blast radius. A single authenticated tunnel can become a general-purpose access path, and that is especially relevant when service access, admin access, and data-plane access are blended. The policy question is not whether forwarding exists, but whether it is intentionally allowed for a named purpose. Teams should map forwarding permissions to approved use cases and remove everything else.

Identity-bound certificates are the cleaner control model for SSH. Static keys create lingering access and weak revocation semantics, while short-lived certificates tie access to an identity and an expiry window. That shifts governance from host-by-host key management to centralized issuance and session-time evaluation. For NHI programmes, that is the difference between scattered access artifacts and enforceable lifecycle control.

Port hardening is useful only when paired with pre-auth controls and algorithm policy. Rate limiting, restricted KexAlgorithms, and modern ciphers reduce abuse and downgrade risk, but they do not solve entitlement sprawl on their own. The field should read this as a reminder that SSH sits at the intersection of transport security, cryptography, and identity management. Practitioners should build layered controls instead of relying on any single change.

From our research:

• 69% of organisations now have more machine identities than human ones, according to The Critical Gaps in Machine Identity Management report.
• 57% of organisations lack a complete inventory of their machine identities, which makes SSH key sprawl and unmanaged access paths harder to govern.
• Use Ultimate Guide to NHIs , Key Challenges and Risks to connect SSH hardening to broader credential inventory and lifecycle controls.

What this signals

SSH governance is converging with NHI governance as organisations move away from static credentials. When access is still mediated by keys, tunnels, and implicit host trust, the programme inherits the same problems seen in broader machine identity sprawl. That is why the operational conversation should shift from server configuration to access lifecycle and entitlement review.

With 57% of organisations lacking a complete inventory of their machine identities, per The Critical Gaps in Machine Identity Management report, SSH keys are rarely the only unmanaged credential. The practical signal for security teams is that unmanaged access often sits in adjacent tooling, not just in the SSH daemon itself.

Identity blast radius: SSH sessions can be low-friction entry points that become high-trust access channels if forwarding and authorization are too broad. Teams should map where shell access can turn into data-plane access, then enforce explicit approvals for those paths. For deeper control design, align SSH policy with the OWASP NHI Top 10 and certificate lifecycle guidance.

For practitioners

• Separate transport changes from identity controls Document SSH port changes as operational hygiene, then review the authentication model, authorized_keys sprawl, and certificate lifecycle as separate governance tasks.
• Disable forwarding where it is not explicitly required Set DisableForwarding yes and verify that X11, agent, and TCP forwarding are not available on systems that only need interactive administrative access.
• Enforce modern cryptographic baselines Remove legacy KexAlgorithms, CBC ciphers, and weak MACs so clients cannot negotiate downgrade-prone session settings.
• Apply pre-auth throttles before exposure Use PerSourcePenalties, nftables, PAM, and related rate limits to reduce brute-force pressure before sshd spends resources on authentication.
• Move privileged access toward short-lived certificates Replace long-lived SSH keys with certificate authorities and short validity windows so access expires automatically and revocation becomes policy-driven.

Key takeaways

• Port 22 is only the entry point, not the security model, so hardening must focus on authentication, forwarding, and cryptographic policy.
• Forwarding and legacy session settings can create more risk than the port number ever will, especially when access is not tied to short-lived identity.
• SSH should be governed as an NHI access path, with certificates, lifecycle control, and pre-auth abuse limits replacing static trust assumptions.

Key terms

• SSH Forwarding: SSH forwarding is the tunnel feature that lets one SSH session carry other traffic through the connection. It can be useful for administration, but it also extends trust beyond the shell if not tightly scoped and explicitly approved.
• Identity-bound Certificate: An identity-bound certificate is a short-lived credential issued to a verified identity and trusted by systems instead of a long-lived key. It improves revocation and expiry handling because access is enforced through the certificate lifecycle rather than distributed static files.
• Pre-auth Defense: Pre-auth defense is the set of controls that act before a server completes authentication, such as rate limits, connection penalties, and filtering. In SSH environments, it reduces brute-force load and limits abuse before the daemon spends full processing effort.
• Cryptographic Floor: A cryptographic floor is the minimum set of algorithms a server will accept during negotiation. In SSH, it prevents clients from forcing weak key exchange, cipher, or MAC choices and is a core part of resisting downgrade and legacy-protocol risk.

What's in the full article

Teleport's full article covers the operational detail this post intentionally leaves for the source:

• Step-by-step SSH hardening settings for port selection, forwarding, and algorithm restrictions.
• Specific OpenSSH directives and sequencing notes for safe firewall, SELinux, and monitoring changes.
• Detailed discussion of certificate authorities versus authorized_keys for production access.
• Examples of pre-auth controls such as PerSourcePenalties, nftables, and PAM tuning.

👉 Teleport's full article covers the configuration details, algorithm choices, and access model comparisons.

Deepen your knowledge

SSH certificate-based access and session governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is still treating SSH as a configuration issue, it is worth exploring.