Harden Linux SSH: Bastion Hosts, 2FA, and Auditing

Table of Contents

Why Linux SSH hardening matters

SSH remains the primary remote access method for Linux servers in production, so Linux SSH hardening is essential to protect systems from credential theft, lateral movement, and unauthorized access. A layered approach that combines a bastion host, enforced key based authentication, multi factor authentication, and centralized auditing reduces risk and improves incident response.

This guide walks through practical, production focused steps you can apply immediately, including commands and configuration snippets for OpenSSH, PAM modules for OTP and YubiKey, auditd and rsyslog forwarding to an ELK stack or SIEM. The goal is a hardened, auditable access path that is still usable for administrators.

Deploy a bastion host as an SSH gateway

A bastion host consolidates SSH access to an isolated gateway, minimizing direct exposure of internal servers. Deploy the bastion in a hardened subnet with strong firewall rules so only the bastion accepts public SSH and it alone can reach internal hosts over SSH.

Key deployment items include network security groups, strict host based access control, and separating user accounts from the bastion OS. Consider these checklist items:

Enable only required inbound ports on the bastion, usually 22 or a non standard port.
Restrict access by source IP ranges where possible, and enable logging and monitoring on the bastion.
Use a jump configuration in SSH client config to force proxying through the bastion.

Enforce SSH keys and disable password auth

Enforcing key based authentication prevents password guessing and credential spraying. On each server update the OpenSSH server config to reject passwords and allow only public key methods. Edit /etc/ssh/sshd_config and set PasswordAuthentication no and PubkeyAuthentication yes.

Deploy keys using a central management process or configuration management tool, and avoid distributing private keys. Example minimal sshd_config changes:

PasswordAuthentication no
ChallengeResponseAuthentication no
PubkeyAuthentication yes
PermitRootLogin no
AllowUsers alice bob@internal-host

Enable multi factor authentication: OTP and YubiKey

Add a second factor to significantly raise the bar for access. For time based OTP, use Google Authenticator PAM or libpam-google-authenticator. For hardware 2FA, use the pam_u2f module to bind YubiKey or FIDO2 tokens to user accounts.

OTP installation example on Debian/Ubuntu:

apt-get install libpam-google-authenticator
# each user runs
google-authenticator

For YubiKey, install pam_u2f and register the token mapping in /etc/u2f_mappings. Modify /etc/pam.d/sshd to include the appropriate auth lines, and set ChallengeResponseAuthentication yes in sshd_config to allow PAM based 2FA.

Centralized audit logging with auditd and rsyslog

Enable auditd on all hosts to capture process execution, file access, and key SSH events like authentication attempts and session starts. Configure audit rules to capture execve, user logins, and changes to sudoers and sshd_config. Use ausearch and aureport for local analysis.

Example audit rule file /etc/audit/rules.d/99-ssh.rules:

-w /etc/ssh/sshd_config -p wa -k ssh_config
-w /var/log/secure -p wa -k ssh_logs
-a always,exit -F arch=b64 -S execve -k execs

Forward logs to ELK or a SIEM

Rsyslog or Filebeat can forward auditd and auth logs to a central ELK stack or a managed SIEM. On the logging host run Elasticsearch, Logstash, and Kibana, or use a modern pipeline with Filebeat to send directly to Elasticsearch if you prefer.

Basic rsyslog remote forwarding example on the client:

# /etc/rsyslog.d/50-remote.conf
*.* @@logserver.example.internal:514
# restart rsyslog
systemctl restart rsyslog

Tag forwarded messages with host metadata to preserve origin.
Index auth and audit logs separately for easier queries and alerts.

SSH hardening best practices

Apply consistent hardening across hosts, including rejecting weak ciphers, limiting user access, and isolating administrative accounts. Update OpenSSH to a supported version, and explicitly set Ciphers, KexAlgorithms, and MACs in sshd_config to accepted values used by your organization.

Other practical measures include:

Use AllowUsers or Match blocks in sshd_config to restrict who can log in where.
Keep separate admin accounts and avoid shared keys, use sudo with full auditing instead.
Rotate keys and require hardware tokens for privileged accounts when feasible.

Troubleshooting common SSH issues

If users report inability to connect after hardening, verify sshd_config syntax with sshd -t and review /var/log/auth.log or journalctl -u sshd. Common causes include PAM misconfiguration, incorrect file permissions on ~/.ssh, and mismatch between server and client supported algorithms.

When audit logs seem incomplete, confirm auditd rules are loaded with auditctl -l and that rsyslog or Filebeat is shipping the correct files. For 2FA failures examine PAM logs and ensure the token mappings are correct on the server.

FAQ

This section answers common operational questions about deploying bastion hosts, 2FA, and audits for Linux SSH hardening.

Q: Can I require both OTP and YubiKey at the same time? Yes, PAM can be configured to require multiple stacked authentication modules. Configure pam to require both pam_u2f and pam_google_authenticator in the correct sequence, and test on a non production account first.
Q: How do I avoid locking myself out when disabling passwords? Keep an active root console or alternative management plane such as out of band management, and test key based login before setting PasswordAuthentication no. Have another admin account with console access available.
Q: What volume of logs will auditd generate? Auditd can be chatty depending on rules. Start with targeted rules for execve, login events, and critical file changes. Monitor disk usage and forward logs to central storage quickly to avoid local retention issues.
Q: Is a bastion host a single point of failure? A single bastion can be a single point of failure, so deploy bastion pairs behind a load balancer or use multiple bastion hosts with synchronized configs and key management for redundancy.

Conclusion

Hardened SSH access on Linux requires both technical controls and operational discipline. By placing a bastion host as a controlled gateway, enforcing key based authentication, and adding multi factor protections with OTP and hardware tokens, you greatly reduce the attack surface for remote access. Centralized audit logging with auditd and rsyslog, forwarded to ELK or a SIEM, provides the visibility needed to detect abuse and investigate incidents quickly.

Implement changes incrementally, test each step in a staging environment, and automate key distribution and log forwarding with your configuration management tools. Continue to rotate keys and maintain up to date SSH configurations, and pair these controls with regular log review and alerting. This layered approach balances security and operational usability, enabling administrators to securely manage Linux infrastructure in production while keeping a clear, auditable trail of access and actions.