Security Openssh-server-sig-algs-fingerprinting-vulnerability
server-sig-algs (7.2 and later, confirmed in 8.9p1 and 9.2p1)OpenSSH servers expose a comprehensive list of compile-time supported signature algorithms in the server-sig-algs extension (sent via SSH2_MSG_EXT_INFO, RFC 8308), even when runtime configuration (e.g., PubkeyAcceptedAlgorithms in sshd_config) restricts client authentication to a subset of these algorithms. This behavior allows remote attackers to fingerprint the server's OpenSSH version and distribution by analyzing the advertised algorithms, including deprecated ones like ssh-dss or modern extensions like sk-ecdsa-sha2-nistp256@openssh.com. This information leakage can aid in identifying unpatched vulnerabilities or tailoring exploits specific to the server's build.
For example, a server configured with PubkeyAcceptedAlgorithms rsa-sha2-256 still advertises server-sig-algs=<ssh-ed25519, ..., ssh-rsa, rsa-sha2-256, rsa-sha2-512, ssh-dss, ...>, revealing support for algorithms not in use and exposing version-specific details (e.g., ssh-dss dropped in 7.0, sk-* added later). Tools like ssh-audit can exploit this to map server characteristics, increasing the attack surface.
server-sig-algs enabled (default since 7.2).ssh -vvv hostname.server-sig-algs in debug output, e.g., kex_input_ext_info: server-sig-algs=<ssh-ed25519, ..., ssh-rsa, rsa-sha2-256, rsa-sha2-512, ssh-dss, ...>.ssh-dss indicates pre-7.0 build.rsa-sha2-512 confirms 6.5+.sk-* algorithms suggest 8.2+.ssh-audit to automate fingerprinting.SSH2_MSG_EXT_INFO by recompiling OpenSSH without extension support (not practical for most users).server-sig-algs based on runtime config (e.g., only list algorithms allowed by PubkeyAcceptedAlgorithms).This vulnerability was identified during an investigation into OpenSSH authentication failures caused by configuration mismatches. The researcher noticed that uncommenting general PubkeyAcceptedAlgorithms settings (e.g., ssh-ed25519,rsa-sha2-512,rsa-sha2-256) in the client's ssh_config disrupted connections to a server restricted to PubkeyAcceptedAlgorithms rsa-sha2-256, even with host-specific overrides. This led to the discovery of three related design flaws:
1. Incomplete Host-Specific Overrides: Host-specific PubkeyAcceptedAlgorithms settings do not fully isolate from general settings, causing unexpected client behavior.
2. Client Retry Absence: The SSH client selects one algorithm per key (e.g., rsa-sha2-512) and does not retry others (e.g., rsa-sha2-256), even when a match exists, breaking expected negotiation flexibility.
3. Server-Sig-Algs Mismatch: The server advertises rsa-sha2-512 in server-sig-algs despite rejecting it for client authentication, misleading the client into attempting an unsupported algorithm.
These issues highlighted the fingerprinting vulnerability: the broad server-sig-algs list exposed compile-time settings unrelated to runtime policy, revealing version and build details. Aligning server-sig-algs with PubkeyAcceptedAlgorithms at runtime would not only mitigate this security risk by reducing information leakage (e.g., advertising only rsa-sha2-256 in the example case) but also enhance usability. Clients could then reliably select supported algorithms, avoiding failed authentication attempts due to mismatches. This dual benefit—improved security and user-friendliness—suggests a design improvement for OpenSSH beyond mere vulnerability patching.