Why SSH security deserves a structured approach
SSH remains one of the most important tools for administering Linux and Unix servers. It is also one of the most attractive paths for an attacker. A stolen private key, an exposed password, an unpatched SSH service or an over-privileged administrator account can provide a direct route to sensitive systems.
Secure server access is not achieved by changing one setting in sshd_config. SSH hardening works when identity, network access, operating system permissions, monitoring and recovery controls support one another. A strong key is useful, but it does not compensate for a key left on an unmanaged laptop. An IP allowlist reduces exposure, but it does not prevent misuse from an approved network.
The goal is to make unauthorised access difficult, limit what a compromised account can do, detect suspicious activity quickly and retain a safe path for legitimate administration during an incident.
Start with the two highest-value SSH hardening changes
Disable direct root login
Direct root login makes accountability and containment harder. Every administrator appears as the same user, and a successful login immediately has unrestricted privileges. Set PermitRootLogin no where operationally appropriate, then require administrators to connect with named accounts and use sudo for privileged actions.
There can be exceptions for carefully designed recovery procedures, but they should be deliberate rather than the default. If a platform requires a root-level emergency path, protect it with a separate key, a restricted source network, strong monitoring and a documented approval process.
Disable password authentication
Password authentication is exposed to guessing, credential stuffing, phishing and password reuse. On servers that support it, disable it with PasswordAuthentication no after confirming that approved key-based access works. Also review related settings such as keyboard-interactive authentication, because some configurations can still permit password-style login through that method.
Do not make this change without testing an active administrative session and a separate new session. A common operational mistake is to close the only working connection before verifying the replacement access method. Keep a controlled console or out-of-band recovery route available for changes that could lock out the team.
Use strong public key authentication properly
Public key authentication is generally safer and more manageable than passwords, but the security of the system depends on both halves of the key pair. The public key belongs in the server's authorised-key configuration. The private key must remain secret and should never be copied into tickets, scripts, shared drives or chat messages.
Prefer modern key types supported by the operating system and OpenSSH version in use. Hardware-backed security keys can provide particularly strong protection because the private key operation takes place on the device and the key is harder to extract. Where hardware-backed keys are not practical, use a strong passphrase and store private keys in an encrypted operating-system key store or a reputable secrets-management system.
Each administrator should have an individual key rather than sharing one team key. Individual keys make it possible to identify the person responsible for a connection, remove one person's access without affecting everyone else and review the age and purpose of each credential. The comment attached to a public key is not a security control, but useful comments can help explain ownership and expiry dates during an audit.
Protect the private key
A private key without a passphrase is effectively a reusable possession credential. If a laptop is stolen or malware reads the key file, an attacker may be able to connect immediately. Use a strong, unique passphrase and load keys into an agent only for as long as necessary. Secure the workstation with full-disk encryption, screen locking, supported operating-system updates and endpoint protection.
Limit file permissions on private keys. On Unix-like systems, a key should normally be readable only by its owner. Backups of private keys require the same care as the originals; an unencrypted copy in a backup repository undermines the protection on the working device. When an administrator leaves, loses a device or suspects compromise, treat the private key as compromised until it has been revoked or removed from every authorised server.
Apply least privilege and separate administrator identities
SSH access should lead to the minimum authority needed for a person's role. A web developer may need to inspect application logs and restart a service, while a systems engineer may need broader operating-system privileges. These responsibilities should not automatically map to unrestricted root access.
Use named accounts and controlled sudo rules to grant specific commands where feasible. Review whether commands can be combined to escape restrictions. For example, permission to run an editor, interpreter or backup utility as root may effectively provide unrestricted access. A least-privilege design must consider the practical impact of each allowed command, not just its name.
Separate everyday administration from high-risk activity. An administrator can use a standard account for email, browsing and routine work, then use a distinct privileged account only when needed. This reduces the chance that a phishing attack or browser compromise immediately inherits server administration rights. It also creates clearer logs and makes privileged activity easier to review.
Service accounts should not be used for interactive administration. Give automation its own identity, key and permissions, and restrict it to the hosts and commands it requires. A deployment account should not also be the account used for database maintenance or emergency recovery.
Choose the right second factor and network boundary
MFA for SSH
Multi-factor authentication can reduce the impact of a stolen private key, especially when the second factor is independent of the administrator's workstation. Common approaches include SSH integration with a one-time-password system, a PAM-based challenge, a central identity provider or a bastion host that enforces MFA before allowing onward access.
MFA design has trade-offs. A one-time code generated on the same compromised laptop as the SSH key may provide less protection than a separate hardware token. A central authentication service can improve control but introduces a dependency that must be monitored and supported during an outage. Some automation cannot complete an interactive MFA challenge, so non-interactive jobs need a different design rather than a permanent MFA bypass on a powerful account.
Where supported, hardware-backed FIDO2 or similar SSH security keys can offer strong phishing resistance. Test compatibility with the chosen client, operating system and recovery process before making them mandatory. Keep a controlled process for replacing a lost token without leaving a hidden permanent backdoor.
IP allowlists, VPNs and bastion hosts
Restricting SSH to known source IP addresses can reduce scanning and opportunistic attacks. A firewall, security group or network access control list can permit port 22 only from an office range, management network or VPN. This is useful, but it is not a complete protection: approved networks can be compromised, addresses can change and an attacker may already be inside the permitted environment.
A VPN creates a separate administrative boundary and can make firewall rules easier to manage. It must still be patched, strongly authenticated and monitored. A bastion host, sometimes called a jump host, concentrates administrative access in a controlled system. It can enforce MFA, record sessions and provide a single point for allowlists and logging. It also becomes a high-value target, so it needs hardened configuration, limited software, rapid patching and a tested recovery path.
Do not expose SSH broadly to the internet simply because key authentication is enabled. At the same time, do not assume that moving SSH to a different port is a security measure. A non-standard port may reduce noise, but it does not replace authentication, patching, network restrictions or monitoring.
Understand SSH agent forwarding risks
SSH agent forwarding is convenient when an administrator connects to one server and then needs to reach another without copying a private key. The remote host can ask the local agent to perform an authentication operation. The private key itself is not transferred, but a compromised remote server may be able to use the forwarded agent while the connection is active.
That risk matters when connecting through servers that are less trusted than the destination. Avoid forwarding an agent by default. Use it only for a specific, understood task, and consider destination constraints, separate keys or a bastion architecture instead. Administrators should know which hosts can reach their agent and should close forwarded sessions promptly.
For automation, prefer short-lived credentials, narrowly scoped deployment keys, workload identity or a secrets manager where the platform supports it. Never place a long-lived administrator private key in a source-code repository or a build image. If a pipeline must use SSH, restrict the key by source, command and destination where possible, and alert on unexpected use.
Rotate, revoke and review access deliberately
Key rotation is not just an annual calendar task. Establish an inventory showing each key owner, purpose, systems, creation date, last use and planned expiry. Remove unused keys from authorized_keys and central access systems. A key with no known owner should be treated as an access risk, not as harmless configuration history.
Revocation must be practical under pressure. Document how to remove a key from individual servers, configuration management, bastions and cloud control planes. If certificates or a central SSH certificate authority are used, define short lifetimes and maintain a reliable revocation process. Test that revoking one administrator does not accidentally remove the access needed by the incident-response team.
Carry out an access review after staff changes, supplier changes, major infrastructure projects and security incidents. Check for:
- Direct root login and password authentication settings.
- Unknown, shared or inactive user accounts.
- Unowned public keys, stale keys and keys without an expiry or review date.
- Overly broad sudo permissions and risky permitted commands.
- Service accounts that allow interactive login.
- Unexpected listening interfaces, firewall rules or public SSH exposure.
- VPN, bastion and MFA membership, including dormant accounts.
- Agent forwarding, port forwarding and other SSH features that are not required.
- Log coverage, clock synchronisation and retention for authentication events.
For a practical checklist, compare your current configuration with current SSH server hardening best practices, then validate every recommendation against your operating model. Generic guidance cannot decide which emergency exceptions your business genuinely needs.
Patch the service and make suspicious access visible
SSH is part of the operating system and should follow the same patching discipline as the rest of the server. Apply security updates to the SSH implementation, operating system, libraries, VPN, bastion and management tools. Prioritise internet-facing systems and define how urgent updates are tested and deployed without leaving critical exposure unresolved.
Enable connection and authentication logging at a level that supports investigation without creating unmanageable noise. Record successful and failed logins, source addresses, usernames, key or certificate identity where available, privilege escalation and changes to authentication configuration. Send important logs to a separate system so an attacker who gains server access cannot quietly erase the evidence.
Alerting should focus on useful signals. Examples include repeated failures against a valid account, a successful login from an unusual country or network, a new public key, root-level activity outside a maintenance window, a disabled logging service or a sudden change to firewall rules. Alerts need an owner and an escalation path; an unreadable stream of low-quality notifications offers little protection.
Rate limiting and tools that temporarily block repeated failures can reduce brute-force noise and resource consumption. They can also block legitimate users behind shared addresses or fail to stop a slow, distributed attack. Use them as one layer alongside strong authentication, network controls, monitoring and a tested response process.
Secure automation and emergency access
Automation often needs SSH access without a person present, which makes design discipline especially important. Create a dedicated account for each meaningful workflow. Restrict its source environment, destination hosts and allowed commands. Store its credential in a controlled secret store or protected runner, limit its lifetime where possible and prevent build logs from printing private keys or connection details.
Review whether the job really needs SSH. A deployment platform, configuration-management system or provider API may offer more specific permissions and better auditability. When SSH is necessary, separate production credentials from development credentials and require an explicit approval for production changes.
Emergency access should be available but rare. Keep a documented break-glass account or console path under controlled custody, with strong authentication, limited membership and clear approval requirements. Monitor every use and review it afterwards. Test the procedure before an outage; an emergency account that has not been exercised may fail because of an expired key, changed network route or forgotten dependency.
Do not solve resilience by keeping a permanent unrestricted backdoor. The recovery path should be protected more carefully than routine access, with offline or separately controlled recovery information where appropriate.
Match SSH controls to the server you actually control
The amount of SSH hardening available depends on the hosting model. With a VPS or dedicated server that the business manages, the customer typically controls the operating system, SSH daemon configuration, firewall rules, user accounts, keys, patching and logging. The exact responsibility may be shared with a managed provider, so confirm who makes changes and who responds to alerts.
On shared hosting, customers generally do not control the server-wide SSH configuration. The hosting operator decides whether SSH is available, which authentication methods are supported, whether shell access is restricted and how the underlying system is patched. A customer may be able to upload a key or use a limited shell, but cannot normally disable root login, change sshd_config or enforce organisation-wide access policies. The distinction between customer-managed VPS infrastructure and shared hosting environments is therefore important: SSH controls depend on who operates the server.
Do not assume that a shared-hosting plan provides the same administrative controls as a VPS or dedicated server. If the business needs operating-system access, named administrator accounts, custom firewall rules, a bastion, detailed SSH logging or server-level backup controls, select an infrastructure model where those responsibilities are clearly assigned.
Connect access security with recovery
Strong SSH controls reduce the likelihood of unauthorised administration, but they cannot guarantee that an account, server or management workstation will never be compromised. Recovery planning must assume that credentials can be stolen and that an attacker may alter or encrypt data.
For servers the customer controls, Safenix provides off-site backup designed for business server recovery. Backup data is encrypted with a key that Safenix never holds, stored in Germany and immutable for the length of the selected retention window. That separation is important: access to the production server should not automatically provide the ability to rewrite every protected backup.
Backups do not replace SSH hardening, and SSH hardening does not replace backups. Verify that backup credentials are separate from routine administrator accounts, that the backup process cannot be casually disabled from a compromised session and that recovery access is documented. Test restoration, not just backup completion, and record who can approve and perform a recovery.
A practical review cycle for agencies and IT teams
Make SSH security part of normal administration rather than a one-time cleanup. A useful review cycle can include a monthly check of failed and unusual logins, a quarterly review of accounts, keys and privileges, and an event-driven review after personnel changes, infrastructure migrations or suspected compromise.
- Inventory every server, SSH endpoint, administrator, automation identity and emergency route.
- Confirm ownership and business purpose for every account and public key.
- Validate root and password login settings, MFA, network boundaries and forwarding options.
- Review sudo rules, service-account permissions and production automation.
- Check patch status, logging, alert routing and time synchronisation.
- Test key revocation, break-glass access, backup isolation and restoration.
- Document exceptions with an owner, reason, expiry date and compensating controls.
The strongest result comes from combining small, verifiable controls: named identities instead of shared accounts, keys instead of passwords, least privilege instead of permanent root access, restricted networks instead of open exposure, and tested recovery instead of hope. That approach makes secure server access more resilient without pretending that any single SSH setting can eliminate risk.