Topic starter
14/05/2026 1:41 pm
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.
Editorial analysis by NHI Mgmt Group, based on content published by Teleport: “SSH Port 22: Custom Ports, Port Forwarding Security, and Production SSH Hardening”.
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.
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.
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.
Practitioner guidance
- Disable forwarding where it is not required Turn off local, remote, and dynamic forwarding on hosts that only need interactive administration.
- 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.
- 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.
Bottom line: SSH hardening is mostly about controlling session authority, not hiding the listener on a different port.
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
👉 Read Teleport's analysis of SSH hardening as an identity control problem →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
14/05/2026 1:42 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: SSH hardening is an identity problem, not a port problem