SSH hardening
Key-based access, no password login where appropriate, a restricted admin path.
Less exposure, controlled login, current software, backups that restore. Hardening lowers risk; it does not remove it.
The hardening job
Operational hardening on machines you already own — not a firewall product, not a pentest, not a vendor partnership.
Typical controls
Key-based access, no password login where appropriate, a restricted admin path.
Allow what the app needs. Do not leave management ports open to the internet.
Named users, sudo policy, and leftover accounts from previous agencies gone.
A cadence that matches restart tolerance.
What is listening, what DNS publishes, and what should not.
Current certificates, sensible protocols, renewal that does not surprise you.
If already compromised, the honest path is often rebuild, not “clean in place”.
What is copied, and a restore test — not only a nightly job never tried.
Bring the host, how people log in today, and whether backups have ever been restored.
FAQ
No. Hardening lowers exposure and improves controls. Residual risk remains, and no engagement can promise a server is fully secure.
We harden the host using appropriate firewalling, SSH controls and TLS. Tooling is chosen for the environment rather than sold as an ADGLOB-branded appliance.
No. This page is host hardening and operational practice. A separate security assessment can be discussed if you need that style of review; it is not assumed here.
If a host is already compromised, the work is investigation and recovery, which may mean rebuild rather than 'cleaning in place'. Hardening is most effective before that happens.