Understanding and replacing Bitvise SSH Server host keys

Properly verified host keys are essential to the security of the SSH protocol. Many clients exist which do not verify a host key. This happens especially with clients which originally support different protocols, and add SSH as yet another one to support. Such clients are not secure to use.

If the client does not verify the server's host key, it renders the connection vulnerable to a man-in-the-middle attack. This means that anyone who is in a network position between the client and the server - including an ISP, or an attacker that gained control of a network gateway - can modify the connection in such a way as to observe, modify, or inject any and all sensitive information without being noticed.

A host key is verified by a client as follows:

  • The client might be configured with the full public key, or several public keys, corresponding to host keys used by the server. When the client connects, it verifies that the server is using one of these host keys.

  • The client might be configured with one or more host key fingerprints it should expect from the server. A host key fingerprint is a cryptographic digest of the public key portion of the host key. The fingerprint is calculated using a hash function such as SHA-256, SHA-1, or MD5. Due to weaknesses in SHA-1 and MD5, the type of fingerprint which is now most recommended is SHA-256.

  • The client might not be configured with a host key, or might expect a different host key than is received from the server. In this case, a secure client must either prevent the connection, or require the user to verify the fingerprint of the received host key.

For more information about how public keys are used in SSH, for both server and client authentication, please see Public keys in SSH.

SSH host key negotiation

Bitvise SSH Server can use multiple host keys - one for each different host key algorithm. Supported host key algorithms include RSA, Ed25519, several ECDSA algorithms, and the legacy DSA host key algorithm.

When a client connects to Bitvise SSH Server, the host key that will be used is determined as follows:

  • The SSH Server sends a list of host key algorithms for which it has host keys that are employed.

  • The client sends a preference list of host key algorithms it supports. Depending on the client, this might be a list of all host key algorithms the client supports, including algorithms for which the client does not trust any host key for this server. Alternately, this could be a list of only those host key algorithms for which the client does know a trusted host key for this server.

  • The host key algorithm that is chosen is the first algorithm named by the client which is also named by the server.

Changing Bitvise SSH Server host keys

An administrator may wish to add or replace one or more host keys of an existing SSH Server instance for reasons such as:

  • The SSH Server may be using an older type or size of key that is no longer recommended in SSH. For example: we recommend replacing any size of DSA host key, and any RSA key smaller than 2048 bits, with a 3072-bit RSA host key.

  • An existing host key could have been exposed to compromise. For example, an administrator might have exported the private key for backup, and there were insufficient controls on the backup to ensure it wasn't accessed in an unauthorized way.

  • Replacement might be mandated by a key rollover policy.

Replacing a host key with the same algorithm

For example, an administrator may wish to replace a 1024-bit RSA host key with a 3072-bit RSA key. The new host key will have a different public key and a different fingerprint which existing clients do not trust. To replace this host key, we recommend the following process:

  • Generate a new host key using the Manage host keys interface in the SSH Server Control Panel, but do not yet employ the key.

  • Distribute either the full new public key, or fingerprints of the new host key, to all clients that need to connect to the SSH Server. Do not send the private key to anyone!

  • Provide client administrators sufficient time to configure trust in the new host key. At this time, previously employed host keys continue to be used for connections.

  • Once all clients have been configured to accept the new host key, employ the new host key in place of the old one.

The old host key of the same algorithm can be kept in the Manage host keys interface in dismissed status, and/or can be removed at the administrator's convenience.

Adding a host key with a different algorithm

For example, an administrator may wish to add a 3072-bit RSA host key to a system that already uses a 1024-bit DSA host key, and has clients trusting the 1024-bit key.

In this case, in theory, the administrator could simply add the new RSA host key, employ it, and leave the DSA host key in place, allowing clients to migrate to the new RSA host key over time.

In practice, however, this will only work if all existing clients that trust the DSA host key either:

  • do not support the RSA host key algorithm at all; or

  • their host key algorithm preference list puts DSA in front of RSA; or

  • no client will request RSA as more preferred than DSA in a situation where it only trusts a DSA key, but not an RSA key.

In practice, when clients connect with a variety of software, all of these conditions may be broken. For example, most clients will support the RSA host key algorithm, and many may prefer it to DSA. In addition, clients that prefer RSA to DSA will send a preference list that prefers RSA even if they trust only a DSA host key for this server, and do not trust any RSA host key.

As a result, with many clients, connections may break immediately as soon as an RSA host key is employed. This can happen even if there is no other reason these clients could not continue to trust the DSA host key that they have always trusted.

For this reason, adding a new host key with a different algorithm needs to follow the following process:

  • Generate a new host key using the Manage host keys interface in the SSH Server Control Panel, but do not yet employ the key.

  • Distribute either the full new public key, or fingerprints of the new host key, to all clients that need to connect to the SSH Server. Do not send the private key to anyone!

  • Provide client administrators sufficient time to configure trust in the new host key.

  • Once all clients have been configured to accept the new host key, employ the new host key.