Weak SSH Configuration

Weak SSH (Secure Shell) configuration encompasses a range of security deficiencies in the deployment and configuration of SSH servers across infrastructure. This includes the use of deprecated cryptographic algorithms (such as DES, 3DES, RC4, or CBC-mode ciphers), weak key exchange methods (diffie-hellman-group1-sha1, diffie-hellman-group14-sha1), legacy protocol versions (SSHv1), insufficient host key sizes (RSA keys smaller than 2048 bits), and insecure authentication configurations such as permitting root login, allowing password-based authentication when key-based auth should be enforced, or having overly permissive authorized_keys configurations.

SSH is the primary remote administration protocol for Linux, Unix, network devices, and increasingly Windows systems. A misconfigured SSH server can undermine the security of the encrypted channel, expose systems to brute-force attacks, or allow unauthorised access through weak authentication mechanisms. Many organisations deploy SSH servers with default configurations that, while functional, do not represent a hardened security posture. The OpenSSH default configuration, for instance, enables password authentication, permits root login (depending on the distribution), and supports legacy cipher suites for backward compatibility.

The threat landscape for SSH includes both targeted attacks against specific hosts and automated mass-scanning campaigns that probe the entire IPv4 address space for SSH servers with weak configurations or credentials. Botnets like Mirai and its variants continuously scan for SSH servers accepting password authentication with weak or default credentials. Nation-state adversaries have been documented exploiting weak SSH configurations and stolen SSH keys for persistent access to critical infrastructure.

Attackers exploit weak SSH configurations through multiple vectors. Weak cryptographic algorithms enable passive decryption or active man-in-the-middle attacks: for example, the Terrapin attack (CVE-2023-48795) exploits vulnerabilities in the SSH handshake to downgrade connection security. CBC-mode ciphers are vulnerable to plaintext recovery attacks, and weak key exchange algorithms like diffie-hellman-group1-sha1 use a 1024-bit prime that is within reach of state-level adversaries. If SSHv1 is enabled, the protocol itself is fundamentally broken and allows session hijacking and credential theft.

Password-based authentication on SSH servers is the primary target for brute-force and credential stuffing attacks. Attackers use tools like Hydra (hydra -L users.txt -P passwords.txt ssh://target), Medusa, Ncrack, or custom scripts to systematically attempt common usernames and passwords. When root login is permitted, attackers can directly target the most privileged account. Even with rate limiting, distributed brute-force attacks from multiple source IPs can bypass per-IP throttling. Credential stuffing using username/password pairs from previous data breaches is also highly effective against SSH servers that allow password authentication.

Stolen or compromised SSH private keys represent another significant attack vector. If private keys are not protected with strong passphrases, or if they are found during post-exploitation of a compromised system (in ~/.ssh/ directories, backup files, or configuration management repositories), attackers gain direct, passwordless access to all systems where the corresponding public key is authorised. Agent forwarding misconfigurations can allow an attacker with access to one system to hijack the SSH agent socket and authenticate to other systems using the victim's forwarded keys.

• Brute-force attacks against password-authenticated SSH sessions leading to system compromise
• Man-in-the-middle attacks exploiting weak cipher suites or key exchange algorithms to intercept encrypted sessions
• Session hijacking through SSHv1 protocol vulnerabilities or Terrapin-style handshake manipulation
• Passive decryption of captured SSH traffic using weakened cryptographic parameters
• Unauthorised root-level access when root login is permitted and credentials are compromised
• Lateral movement using compromised SSH keys found during post-exploitation that grant access to additional systems
• Persistent access through implanted SSH keys in authorized_keys files that survive password changes
• Compliance violations with standards requiring strong encryption (PCI DSS, FIPS 140-2, NIST SP 800-52)

1. Disable SSHv1 entirely and ensure only SSHv2 is permitted by setting Protocol 2 in sshd_config (though this is the default in modern OpenSSH, it should be explicitly verified)
2. Restrict cipher suites to strong, modern algorithms only. Recommended sshd_config settings: Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
3. Restrict key exchange algorithms: KexAlgorithms sntrup761x25519-sha512@openssh.com,curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512
4. Restrict MAC algorithms: MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com
5. Disable password authentication and enforce key-based authentication: PasswordAuthentication no, ChallengeResponseAuthentication no, PubkeyAuthentication yes
6. Disable root login: PermitRootLogin no (or prohibit-password at minimum if root key-based access is operationally required)
7. Generate strong host keys (minimum RSA 4096-bit or Ed25519) and remove any host keys smaller than 2048 bits. Regenerate with ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key
8. Implement SSH hardening measures: MaxAuthTries 3, LoginGraceTime 30, AllowUsers or AllowGroups directives, and disable agent forwarding (AllowAgentForwarding no) and TCP forwarding (AllowTcpForwarding no) unless explicitly required

The primary tool for SSH configuration auditing is ssh-audit, which provides comprehensive analysis of SSH server algorithms and configuration: ssh-audit target_ip. This tool identifies weak ciphers, key exchange algorithms, MAC algorithms, and host key types, colour-coding them by severity. It also checks for known vulnerabilities affecting the specific SSH server version. Run ssh-audit against all SSH servers in scope and document any algorithms flagged as weak, deprecated, or vulnerable.

Supplement ssh-audit with Nmap NSE scripts for additional checks: nmap -p 22 --script ssh2-enum-algos,ssh-hostkey,ssh-auth-methods target_range. The ssh2-enum-algos script enumerates all supported algorithms, ssh-hostkey retrieves and analyses host keys (checking key sizes), and ssh-auth-methods determines which authentication methods are accepted (password, publickey, keyboard-interactive). Check for SSHv1 support: nmap -p 22 --script sshv1 target.

Test for weak credential vulnerabilities by conducting authorised brute-force testing against SSH servers that accept password authentication. Use Hydra with targeted wordlists: hydra -L users.txt -P /usr/share/seclists/Passwords/Common-Credentials/top-1000.txt -t 4 ssh://target. Check for SSH key reuse by collecting all public host keys and searching for duplicates across the environment. Verify that the Terrapin vulnerability (CVE-2023-48795) is mitigated by checking for the strict-kex extension. For each finding, document the specific weak algorithm or configuration, the affected host, the tool output as evidence, and the recommended hardened configuration setting.