TL;DR: Teleport shows that SSH port choice mainly changes scan noise and logging volume, while the real SSH risk sits in forwarding rules, algorithm negotiation, authentication policy, and credential lifecycle. Hardening SSH only becomes meaningful when teams treat it as an identity and access control problem, not a single network setting.
At a glance
What this is: Teleport argues that SSH hardening is driven by authentication, forwarding, and cryptographic policy, not by changing port 22 alone.
Why it matters: IAM and PAM teams should treat SSH as an identity control surface because the real exposure comes from who can connect, what they can tunnel, and how access is revoked.
👉 Read Teleport's analysis of SSH hardening as an identity control problem
Context
SSH hardening often gets reduced to changing the listening port or disabling root login, but that framing misses the actual control surface. SSH is an identity and access path problem because the session outcome depends on authentication rules, key exchange choices, forwarding permissions, and whether access is still valid at connection time.
Port 22 itself is only the TCP entry point for the handshake. Once a connection exists, the security posture is determined by sshd_config, credential type, forwarding controls, and the surrounding operational guardrails. That makes SSH a governance problem for NHI and human access alike, especially where static keys or broad forwarding permissions still shape production access.
Key questions
Q: What breaks when SSH hardening stops at changing the port?
A: You still leave authentication policy, forwarding, and cryptographic negotiation untouched, so the service remains exposed to the same real abuse paths. Port changes may reduce noise in logs, but they do not prevent tunnelling, weak algorithm use, or credential-based access to sensitive systems.
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: How can security teams tell whether SSH hardening is actually working?
A: The strongest sign is that access depends on time-bound identity and explicit policy rather than reusable keys, broad forwarding, or default algorithm negotiation. If sessions are still granted through static trust or open tunnels, the environment is only cosmetically hardened.
Q: What is the difference between SSH port hardening and SSH identity hardening?
A: Port hardening changes where connections land and may reduce opportunistic scanning. Identity hardening changes who can connect, how they authenticate, what they can forward, and when access expires, which is the part that actually governs risk in production.
Technical breakdown
Why port 22 is not the control that matters
Port 22 is just the default network listener for SSH. It changes where traffic lands, but it does not decide which algorithms are negotiated, how users authenticate, or what they are allowed to do after login. Moving SSH to another port can reduce opportunistic scanning noise, yet a hardened service on port 22 is still safer than an exposed service on a custom port with weak ciphers, password logins, or permissive forwarding. The important distinction is between transport exposure and session governance.
Practical implication: treat port changes as noise reduction only, not as a substitute for identity and session controls.
How SSH forwarding expands the access boundary
SSH forwarding turns an interactive session into a tunnelling channel. Local forwarding exposes a destination through the client session, remote forwarding can create reverse tunnels back into an internal service, and dynamic forwarding can act as a SOCKS proxy for arbitrary traffic. That means SSH can become a path around network controls, especially when GatewayPorts or broad binding choices extend exposure beyond the intended host. Forwarding is therefore not a convenience feature alone; it is an access-extension mechanism that changes the effective security boundary of the session.
Practical implication: disable forwarding wherever the use case is interactive access only, and explicitly constrain any allowed tunnel paths.
Why algorithm and authentication policy define the real SSH floor
SSH negotiation only stays strong if the server removes weak options from the list it advertises. KexAlgorithms, ciphers, and MACs set the minimum acceptable cryptographic posture, while authentication settings decide whether access depends on passwords, keys, or certificates. A permissive configuration can still negotiate down to legacy algorithms or accept credentials that should no longer exist. Teleport’s broader point is that access should be evaluated at session time, not assumed safe because a port changed or an SSH daemon is reachable.
Practical implication: restrict weak algorithms, remove password-based access where possible, and move toward certificate-based authentication for time-bound SSH sessions.
Threat narrative
Attacker objective: The attacker wants a trusted SSH session that can be reused to reach internal resources, bypass controls, or move traffic through the network undetected.
- Entry begins with an internet-facing SSH listener that attracts automated scanning, credential stuffing, and brute-force traffic on the exposed port.
- Escalation happens when permissive forwarding, weak algorithms, or password authentication allow an attacker or compromised client to extend the session into other network paths.
- Impact follows when the SSH channel becomes a general-purpose tunnelling route for bypassing network controls, exfiltration, or unauthorized access to internal services.
Breaches seen in the wild
- CI/CD pipeline exploitation case study: Credentials in an exposed .git/config let a researcher edit a Bitbucket pipeline so it planted their SSH key on the server. No victim was named.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
SSH hardening fails when teams confuse exposure with authority: Changing the listening port reduces opportunistic scanning, but it does not change who is trusted, what they can reach, or how access is revoked. The control plane is still authentication, authorization, and forwarding policy. For identity programmes, the point is simple: network obscurity never substitutes for governed access.
Forwarding is the real blast-radius multiplier: Local, remote, and dynamic forwarding each turn a login channel into a broader access path. That means SSH is not only an endpoint access mechanism, it is a session-level transport for policy bypass if forwarding is left open by default. The identity lesson is that session capability, not port number, determines practical reach.
Certificate-based SSH changes the governance model, not just the credential type: Static keys and long-lived authorized_keys entries force revocation to happen indirectly through configuration drift. Short-lived certificates move expiry, revocation, and scope into the credential itself. That is the governance shift teams should notice: access becomes time-bound and identity-bound instead of host-bound and file-bound.
Runtime evaluation beats static configuration for production SSH: A hardened SSH deployment still relies on decisions made in the past if access is granted through keys copied around hosts. Identity-bound certificates, session recording, and role evaluation at connection time align SSH with modern governance expectations. The practical conclusion is that access should be decided when the session starts, not inherited from old configuration state.
Custom ports solve a logging problem, not a trust problem: The article’s central concept is identity-first SSH hardening. That framing matters because it exposes the underlying governance assumption: if access is protected by where the service listens, then the organisation is still treating transport as the control. The implication is to reframe SSH as a governed identity path, not a hardened port.
What this signals
Identity-first SSH hardening: The useful unit of control is the session, not the port. Once teams see SSH as a governed identity path, they can separate operational noise reduction from real access reduction and stop mistaking custom ports for a security boundary.
Access reviews for SSH are weak when the organisation still relies on static keys scattered across hosts. Certificates and role-based session evaluation shift the decision to connection time, which is where practical governance belongs.
For practitioners
- Disable forwarding where it is not required Turn off local, remote, and dynamic forwarding on hosts that only need interactive administration. Where a tunnel is genuinely required, scope it tightly and document the business case so SSH does not become a general-purpose proxy path.
- Restrict SSH to modern cryptographic algorithms Remove legacy key exchange, cipher, and MAC options from server policy so the session cannot negotiate down to weaker choices. Keep the allowed set explicit rather than relying on defaults or client preference.
- Replace static keys with short-lived certificates Use certificate-based authentication so access expires by design and revocation is handled through the credential lifecycle instead of manual cleanup across hosts. This reduces the persistence of stale SSH trust.
- Treat port changes as a coordinated control change If you move SSH off port 22, update firewall rules, SELinux policy, client configuration, ProxyJump chains, and monitoring before closing the original path. The port change itself is not the hardening outcome.
- Audit pre-auth defenses and rate limits Set explicit limits for authentication attempts, unauthenticated session duration, and connection concurrency so brute-force traffic is throttled before sshd spends unnecessary resources processing it.
Key takeaways
- SSH hardening is mostly about controlling session authority, not hiding the listener on a different port.
- Forwarding, algorithm policy, and authentication method determine the real attack surface for SSH.
- Short-lived certificates and session-time authorization offer a stronger governance model than static keys and indirect revocation.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5, NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The article centres on SSH authentication choices and trust in long-lived credentials. |
| NHI-07 — Long-Lived Secrets | Static SSH keys and durable trust state are the core governance weakness discussed here. | |
| NHI-10 — Human Use of NHI | The article contrasts human-operated SSH access with identity-bound, governed session access. | |
| Recommendation — Replace reusable SSH credentials with stronger authentication and session-time identity checks. Reduce long-lived SSH secrets by moving access to short-lived, expiring credentials. Limit human handling of SSH secrets and centralise access through governed identity flows. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | SSH key and certificate lifecycle management maps directly to authenticator governance. |
| AC-6 — Least Privilege | Forwarding and broad SSH reach expand privilege beyond what most sessions require. | |
| Recommendation — Manage SSH authenticators with explicit issuance, rotation, and revocation controls. Restrict SSH permissions and forwarding paths to the minimum required for each role. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about who may connect and what they may do after connecting. |
| Recommendation — Review SSH permissions and entitlements as governed access, not as a port configuration issue. | ||
| NIST Zero Trust (SP 800-207) | 3.4 — Access enforcement and policy evaluation | SSH hardening is framed as policy evaluation at connection time rather than network exposure alone. |
| Recommendation — Apply policy checks at SSH session start instead of relying on static network placement. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The article describes brute-force access, forwarding abuse, and tunnel-based path extension. |
| Recommendation — Map SSH abuse patterns to credential access and lateral movement to improve detection priorities. | ||
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.
- Certificate-based authentication: A method of proving identity using a cryptographic certificate and the associated private key rather than a reusable password. In identity programmes, it raises the bar for theft and replay because the secret is bound to lifecycle, issuance, and revocation control.
- SSH Authenticator Lifecycle: SSH authenticator lifecycle is the governance of how keys, certificates, and related trust material are issued, used, rotated, and revoked. For SSH, poor lifecycle management leaves stale access paths in place long after the original need has ended, especially in distributed environments.
- Session-Time Authorization: Session-time authorization means access is evaluated at the moment a connection starts, based on current identity and policy conditions. In SSH environments, this is stronger than relying on historical configuration because it reduces the chance that old trust state continues to grant active access.
What's in the full article
Teleport's full article covers the operational detail this post intentionally leaves for the source:
- Exact sshd_config directives for forwarding, algorithms, and authentication controls
- Step-by-step guidance for changing port 22 without locking yourself out
- Operational notes on SELinux, ProxyJump chains, and monitoring updates after a port move
- Comparison of authorized_keys and certificate authorities for SSH access
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on May 14, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org