Which ECDSA Public Key in a Windows 10 OpenSSH Server Will Be Used?

The Windows 10 OpenSSH server selects an ECDSA public key based on the negotiation order defined in the sshd_config file, specifically within the HostKey directives. If no specific configuration overrides the defaults, the server presents available keys to the client, which then chooses the strongest mutually supported algorithm. The primary determinant is not a single hardcoded key but the priority list established by the system administrator or the default installation sequence.

Understanding HostKey Configuration

The core mechanism for key selection lies in the HostKey directive found in the sshd_config file located at C:\ProgramData\ssh\sshd_config. This file dictates the order in which the SSH daemon presents its host keys during the connection handshake. When a client connects, it receives a list of available keys and their associated algorithms. The server does not arbitrarily pick one; rather, it offers them in the order specified by the configuration file. If you have multiple ECDSA keys installed, such as ecdsa-sha2-nistp256 and ecdsa-sha2-nistp384, the server will offer them according to their position in the HostKey lines. For example, if the configuration lists the NIST P-256 key first, that key will be presented first. However, modern SSH clients are intelligent and may reject weaker keys even if they appear earlier in the list, preferring stronger cryptographic standards like Ed25519 or larger ECDSA curves if supported. It is crucial to understand that the "selected" key is ultimately determined by mutual agreement between the client and the server. The server provides options, but the client enforces security policies. Therefore, simply placing a key in the directory does not guarantee its use if the client refuses it due to security constraints or if another stronger key is preferred.

Default Key Locations

By default, the Windows 10 OpenSSH server installs keys into C:\ProgramData\ssh\. The standard filenames typically follow the pattern ssh_host_ecdsa_key for the private key and ssh_host_ecdsa_key.pub for the public key. There is usually only one pair generated by default during installation, corresponding to the NIST P-256 curve. If you generate additional ECDSA keys with different curves (e.g., P-384 or P-521), you must explicitly add them to the sshd_config file using additional HostKey directives pointing to those new private key files. Without these explicit entries, the server ignores any extra key files present in the directory. This behavior ensures that administrators have full control over which cryptographic materials are exposed to network connections. For users managing complex environments, it is common to see multiple HostKey lines in the configuration file. Each line points to a different private key file. The server reads these lines sequentially and makes each corresponding public key available for authentication. This allows for backward compatibility with older clients that might not support newer, stronger algorithms, while still offering the best security to modern clients.

Determining the Active Key

To identify which ECDSA key is currently being used or offered, you can inspect the running configuration and the active process. One method is to check the sshd_config file for all HostKey entries. You can also use the ssh-keygen command to list the contents of the key files if you need to verify their algorithms. Another approach is to connect to the server with verbose logging enabled from the client side. Using the command ssh -v user@host reveals the exact exchange of keys during the handshake. Look for lines indicating "Server host key" and note the algorithm identifier, such as ecdsa-sha2-nistp256. This output confirms exactly which key the server offered and which one was accepted. If you suspect the wrong key is being used, ensure that the HostKey directives in sshd_config are correctly ordered and that the file paths are accurate. After modifying the configuration, you must restart the SSH service for changes to take effect. Use the command Restart-Service sshd in PowerShell to apply the new settings.

Client-Side Influence

While the server defines the pool of available keys, the client plays a significant role in selection. Modern versions of OpenSSH on Linux, macOS, and Windows prioritize Ed25519 keys over ECDSA and RSA keys if both are available. This means that even if your Windows server has multiple ECDSA keys configured, a modern client might skip them entirely in favor of an Ed25519 key if one is also present and configured on the server. This prioritization is part of ongoing efforts to phase out older, potentially vulnerable algorithms. Consequently, relying solely on ECDSA keys might result in them never being used in practice if stronger alternatives are available. Administrators should consider migrating to Ed25519 keys for new deployments to ensure optimal security and performance.

Best Practices for Key Management

Maintaining a clear and documented sshd_config file is essential for troubleshooting key selection issues. Always comment out unused HostKey directives to avoid confusion. Regularly audit the keys in use to ensure they meet current security standards. Remove any keys that rely on deprecated curves or weak hash functions. Additionally, monitor server logs for any authentication failures related to key mismatches. The Windows Event Viewer, under Applications and Services Logs > OpenSSH, provides detailed information about connection attempts and key exchanges. This data can help diagnose why a specific key might be rejected or why a connection fails unexpectedly. For more information on setting up Cygwin environments alongside Windows tools, you might find Windows 10: Cygwin Setup Running but Displays a Zero Progress Bar useful for resolving setup anomalies. Similarly, understanding terminal configurations can aid in debugging connection issues, as seen in Running Cygwin Terminal with Current Cygwin Installation on Windows 10.

Frequently Asked Questions

Can I force the server to use a specific ECDSA key?

Yes, you can influence the selection by ordering the HostKey directives in sshd_config. Place the desired key's path first in the list. However, remember that the client may still reject it if it prefers a different algorithm or key type available on the server.

What happens if I have multiple ECDSA keys but no Ed25519 key?

If Ed25519 keys are absent, the server will offer the ECDSA keys in the order specified by the HostKey directives. The client will then choose the first acceptable ECDSA key based on its own security policy and supported algorithms.

How do I check which keys are loaded by the SSH daemon?

You can check the running configuration by examining the sshd_config file. Additionally, you can use the ssh-keygen -l -f /path/to/key command to view details of specific key files. The server log in Event Viewer also shows which keys were presented during successful connections.

Does the size of the ECDSA key matter for selection?

Yes, larger keys like NIST P-384 or P-521 provide higher security levels than P-256. Modern clients often prefer larger keys if available. Ensure your sshd_config includes the larger keys if you want to promote their use over smaller, less secure variants.

Why is my client ignoring my ECDSA key configuration?

Your client might be ignoring the ECDSA key because it supports a stronger algorithm like Ed25519, which is also configured on the server. Clients prioritize security, so they will skip weaker keys if better options are available. Check if an Ed25519 key exists in your HostKey list.