Notifications
Clear all
Topic starter
14/05/2026 1:41 pm
TL;DR: SSH port selection mainly affects logging noise and exposure to opportunistic scans, while real risk comes from forwarding rules, algorithm choices, and authentication policy, according to Teleport. The practical lesson is that SSH hardening only matters when it is treated as an identity and access control problem, not a single setting change.
NHIMG editorial — based on content published by Teleport: SSH Port 22, custom ports, port forwarding security, and production SSH hardening
Questions worth separating out
Q: How should security teams harden SSH without relying on port changes alone?
A: Teams should treat SSH as an identity and access problem.
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: What is the difference between changing port 22 and real SSH hardening?
A: Changing port 22 mostly reduces background scanning noise.
Practitioner guidance
- 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.
That is why the operational conversation should shift from server configuration to access lifecycle and entitlement review?
👉 Read Teleport's SSH hardening guidance on ports, forwarding, and certificates →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
14/05/2026 1:42 pm
A few things worth adding from our research at NHI Mgmt Group.
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: SSH hardening is an identity problem, not a port problem
