Upgrading DSA keys

A noticeable pain for a proportion of users of Bitvise software versions 6.xx and older is that:

  • Versions 7.xx - 9.xx support standard (1024-bit) DSA keys, but disable them by default.

  • Versions 7.xx do not support non-standard DSA keys. These are DSA keys larger than 1024 bits. Versions 8.xx - 9.xx support these keys, but disable them by default.

In addition, recent versions of OpenSSH have also removed support for DSA completely.

Before continuing, we recommend that you are familiar with Public keys in SSH.

Problems with DSA keys

The following are some problems with non-standard (larger than 1024-bit) DSA keys in SSH:

  • There is no specification for them. The keys that are used in practice are incompatible with the NIST standard for large DSA keys.

  • At a time when these keys were supported by OpenSSH (they have not been for a decade), OpenSSH incorrectly generated them without enlarging the subgroup size compared to 1024-bit keys. Software derived from these old versions of OpenSSH is still in use on some platforms. Keys generated by such software are likely to be no stronger than 1024-bit DSA keys. Such keys have a deceptive size and are less secure than intended.

The following is true in general for DSA keys in SSH:

  • DSA signatures are highly sensitive to the quality of randomness used in signing. If the random number generator is flawed even in a minor way, the private key can be extracted from the signatures. If the same random parameter is ever used to sign two messages, e.g. due to a bad random seed or a virtual machine restore, the private key can be extracted from only these two signatures.

  • The IETF standards body has decided not to pursue a standard to use DSA keys in SSH with SHA-2 hashing. Any DSA keys used in SSH therefore must use SHA-1, which is no longer recommended for use in signing, and is in some places prohibited. In newer SSH implementations, RSA keys can use SHA-2 hashing. ECDSA keys always use SHA-2.

The main reason DSA was designed is because RSA was encumbered with patents. These patents have since expired. We recommend that any use of DSA keys, non-standard or standard, is replaced with 3072-bit RSA keys or with ECDSA keys. Large RSA keys are likely to be supported in all environments that support large DSA keys.

Checking for DSA keys in Bitvise SSH Client

In the graphical SSH Client, check the following locations to find whether your use relies on DSA keys:

  • Check the Host key manager interface for any DSA host keys saved for servers you connect to.

  • Check the Client key manager interface for any DSA keys used for client authentication.

Newer SSH Client versions additionally support storing host keys and client authentication keypairs in individual profiles. However, those versions also no longer support non-standard DSA keys, so such keys would not be stored there.

In addition, if you are using command line clients such as sftpc, stnlc, stermc, sexec:

  • Your usage may rely on DSA client authentication keys stored in files and passed using the -keypairFile=... parameter. You may need to import such files using the SSH Client's Client key manager to verify the key type they contain.

  • Your usage may rely on DSA host keys stored in files and passed using the -hostKeyFile=... parameter, or host keys that are not stored at all, whose fingerprints are passed using -hostKeyFp=... and older fingerprint parameters. You will need to take manual steps to determine the types of such host keys.

Checking for DSA keys in Bitvise SSH Server

If you have an SSH Server configuration with a small number of accounts, then look for non-standard DSA keys in the following locations:

  • SSH Server host keypairs, under Manage host keys in the SSH Server Control Panel.

  • User authentication keys in each virtual or Windows account settings entry.

If you have an SSH Server configuration with a large number of accounts, you can use the following PowerShell script to check your settings automatically:

Find DSA keys in SSH Server settings

The script needs to be run in an elevated, administrative PowerShell or Command Prompt window, on the computer where the SSH Server is installed. If there are multiple SSH Server instances installed simultaneously, you may need to alter the script so it invokes $cfg.SetInstance to select the intended instance.

To use the above script, the SSH Server version where it is run must be already upgraded. If you wish to use this script before upgrading a production installation from an older version, you will need to:

  • Make a temporary new-version installation. It does not need to be activated or started.

  • Export settings from the older-version installation.

  • Import settings on the new-version installation.

  • Run the script against the new-version installation.

Upgrading a DSA host key

If you find that your SSH Server uses a DSA host key - be it standard or non-standard - we recommend replacing it with a 3072-bit RSA key, or with an ECDSA key.

Replacing a host key is a non-trivial process. We recommend the following page for more information:

Understanding and replacing Bitvise SSH Server host keys

Upgrading DSA client authentication keys

To upgrade a DSA client authentication key:

  • A new key of a desirable algorithm needs to be generated on the client. We recommend a 3072-bit RSA key, or an ECDSA key.

  • The public key corresponding to the new client keypair needs to be uploaded or otherwise sent to the server.

  • Server settings need to be configured with the new client public key.

If the server is Bitvise SSH Server, we recommend the Public key authentication section of our SSH Server Usage FAQ.

Continuing to use DSA keys

Sometimes, replacing keys is just not practical, even if they are known to be problematic. You can upgrade to the latest Bitvise software versions and continue to use DSA keys of any size.

If you upgrade to a new Bitvise SSH Server version from a 6.xx or older installation, support for DSA will be automatically enabled. However, if you create a new installation, it will be disabled. To enable support, you can enable the ssh-dss algorithm in Advanced settings, under Algorithms > Signature.

If you upgrade a previously existing Bitvise SSH Client profile saved by a 6.xx or older installation, support for DSA will be automatically enabled in that profile. However, if you create a new profile, it will be disabled.

To enable support for DSA in the graphical SSH Client, you can enable the DSA algorithm on the SSH tab, under Host keys.

To enable support for DSA in command line clients including sftpc, stnlc, stermc, sexec, you can use a profile in which DSA has been enabled, using the -profile=... parameter. Alternately, you can enable DSA with the parameter -hkeyMod=DSA.