OpenSSH Server Administration: sshd_config Hardening & Cryptographic Security

Secure Shell (SSH) is the ubiquitous remote administration protocol across the global Linux enterprise ecosystem. Because SSH daemon (sshd) listeners are frequently internet-facing or exposed across enterprise management VLANs, they are the primary target for automated credential brute-forcing, dictionary attacks, and unauthorized reconnaissance.

Default distribution configurations prioritize backwards compatibility and ease of deployment over rigorous security. Hardening OpenSSH by establishing strict cryptographic policies, enforcing asymmetric key authentication, integrating multi-factor authentication, and disabling legacy ciphers transforms an exposed remote terminal into a fortified enterprise gateway.

Architecture of the OpenSSH Daemon

On modern systemd-based distributions (RHEL, Rocky Linux, Ubuntu, Debian), the OpenSSH server executes as the sshd.service unit. Its runtime configuration is defined in a hierarchical directory structure:

• /etc/ssh/sshd_config: The primary daemon configuration file.
• /etc/ssh/sshd_config.d/*.conf: Modern drop-in directory where custom administrative overrides should be placed to survive package updates intact.
• ~/.ssh/authorized_keys: User-specific repository containing public cryptographic keys authorized to open sessions.
• /etc/ssh/ssh_host_*_key: Asymmetric host keys proving the server's cryptographic identity to connecting clients.

Core Security Directives in sshd_config

The following directives form the operational baseline for an enterprise hardened OpenSSH deployment:

SSH Key Pair Generation: Ed25519 Defaults & Modern RSA Clarifications

Selecting the appropriate public key algorithm is a critical foundational step in SSH administration. Modern cryptographic baselines distinguish between key types and signature negotiation algorithms:

• Ed25519 as the Modern Default: Edwards-curve Digital Signature Algorithm (Ed25519) is strongly recommended as the default for all new key pairs where client and server compatibility permits. It provides security equivalent to roughly 3000-bit symmetric keys with compact 256-bit public keys, executes constant-time signature generation that naturally resists side-channel attacks, and delivers outstanding performance.
• Modern RSA with RSA-SHA2 Signatures: RSA keys should not be described generally as obsolete or insecure. RSA keys of sufficient length (3072 or 4096 bits) remain fully secure and supported across modern enterprise environments when paired with modern SHA-2 signatures.
• Distinguishing RSA Keys from the Legacy ssh-rsa Signature Algorithm: It is crucial not to conflate RSA keys with the legacy ssh-rsa signature algorithm. Starting in OpenSSH 8.8 (and adopted across enterprise distributions including Ubuntu 22.04 LTS+, Debian 12+, and RHEL 9+), OpenSSH disabled the legacy ssh-rsa signature algorithm by default because it relied on the cryptographically broken SHA-1 hash algorithm.
• Seamless Negotiation via RFC 8332: Modern OpenSSH clients and servers negotiate updated SHA-2-based signature schemes—specifically rsa-sha2-512 and rsa-sha2-256 (defined in RFC 8332)—for existing and new RSA keys. As a result, standard RSA authentication continues to function securely without requiring changes to existing authorized keys, provided the client software supports RFC 8332.

# 1. Recommended: Generate modern Ed25519 key pair with key derivation rounds
ssh-keygen -t ed25519 -a 100 -C "admin@corp.domain"

# 2. Compatibility alternative: Generate strong 4096-bit RSA key pair (uses rsa-sha2 on OpenSSH 8.8+)
ssh-keygen -t rsa -b 4096 -C "admin@corp.domain"

# 3. Transfer public key securely to target Linux host
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@192.168.10.50

Production-Grade Hardened Configuration

Below is an enterprise drop-in configuration file implementing strict modern security standards:

# Listener & Protocol Configuration
Port 2222
AddressFamily inet
Protocol 2

# Authentication & Access Control
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
PermitEmptyPasswords no
MaxAuthTries 3
MaxSessions 5
AllowGroups sysadmins devops

# Cryptographic Policy: Modern Key Exchange & Ciphers (Reject SHA-1/CBC)
KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com

# Session Management & Forwarding
X11Forwarding no
AllowTcpForwarding no
AllowAgentForwarding no
ClientAliveInterval 300
ClientAliveCountMax 2

Testing and Safe Daemon Reloading

Before restarting or reloading the OpenSSH daemon after modifying configuration files, administrators must always test configuration syntax. A syntax error in sshd_config will crash the daemon on reload, permanently locking administrators out of remote headless systems.

# 1. Test configuration syntax (returns 0 and silent output if completely valid)
sudo sshd -t

# 2. Reload the daemon without dropping existing active connections
sudo systemctl reload sshd

# 3. Verify listener status on the new custom port
sudo ss -tulpn | grep sshd

Auditing and Troubleshooting OpenSSH Failures

When remote authentication fails, inspect real-time daemon logs to diagnose the exact failure point:

# Monitor real-time authentication logs on systemd systems
sudo journalctl -u sshd -f

# On Debian/Ubuntu traditional log paths
sudo tail -f /var/log/auth.log

# On RHEL/Rocky traditional log paths
sudo tail -f /var/log/secure

# Client-side deep debug mode (reveals offered public keys and cipher negotiation)
ssh -vvv -p 2222 admin@server.internal

Summary

Securing the OpenSSH daemon is an essential baseline operational requirement for all Linux infrastructure engineers. By replacing legacy password authentication with modern Ed25519 asymmetric cryptography, blocking direct root access in favor of named administrative roles, restricting access via AllowGroups, and pre-testing configurations with sshd -t, organizations neutralize brute-force exposure and build resilient access boundaries across the fleet.