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 a new host key, which the clients prefer, is employed. This can happen even if there is no other reason these clients could not continue to trust the old host keys 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.
Migrating host keys to a new server
If an SSH Server is migrated to a new installation, it makes sense to migrate host keys only if:
The server move is transparent to clients. Clients must continue to connect using the same DNS name or IP address, and the same TCP port, which they used to connect to the previous SSH Server instance.
If clients need to connect to a new DNS name or IP address, or a different port, then client configuration changes are required. In this case, new host keys should be used. Without explicit configuration steps, clients will not trust the same host keys when connecting to a different server address.
The host keys used by the previous server are not outdated. In the interest of compatibility, you can migrate a 1024-bit DSA host key to a new SSH Server instance. However, we recommend replacing such host keys with new and stronger keys. This involves steps and considerations described in previous sections.
To migrate host keys to a new installation:
Export host keys from the previous installation using the Manage host keys interface in the SSH Server Control Panel. You can select multiple host keys and export them in Bitvise format. To use the host keys on a new server, you need to export the keypairs, not the public key only.
Use the Manage host keys interface on the new installation to dismiss or delete any new host keys that were generated during installation. If the keys were never used, it's best to delete to avoid confusion. Generating new keys is easy, it's configuring clients that's hard.
Use the same interface to import the migrated host keys. Employ the migrated host keys, so they will be used for SSH and SFTP connections.