EldoS | Feel safer!

Software components for data protection, secure storage and transfer

SFTP OnKeyValidate unexpected key changes

Posted: 08/05/2015 16:46:40
by Zoë Peterson (Priority Standard support level)
Joined: 05/24/2007
Posts: 23

In our SSH client OnKeyValidate handler we're doing the recommended approach of prompting the first time we see a key, saving if requested, and giving an enhanced warning if the key is different than the key we saw previously.

We're now seeing "Key changed!" messages in the new version of our application even though the server configuration hasn't changed. I'm assuming this is due to the addition of ECDSA support in SBB 13, since the keys are in fact different.

Is there anything we can do to avoid the warning in this case? Possibly prioritize RSA if we have an existing saved key, for example? Or is there a different way to save the key that will avoid this if there are similar changes in the future? Right now we're using SavePublicKey(kfOpenSSH).
Posted: 08/05/2015 18:16:08
by Ken Ivanov (Team)

Hi Zoë,

Thank you for contacting us.

Your idea about priorities if perfectly correct.

The public key algorithm to be used during SSH negotiation is chosen by the parties mutually depending on the order of the algorithms in their 'hello' messages. Algorithms that come first in the list have a higher priority than those at the end of the list.

By default, all algorithms supported in SSHBlackbox have equal priority. That is, it is possible that the parties started negotiating ECDSA instead of RSA after upgrading to SBB 13. To override this, it makes sense to increase the priorities of RSA and DSS algorithms (to some positive value, e.g. 10) and leave the priority of ECDSA algorithm at its original value (0). This will make the component negotiate 'old' RSA or DSA algorithms in favour of ECDSA and reuse the known keys.

Or is there a different way to save the key that will avoid this if there are similar changes in the future? Right now we're using SavePublicKey(kfOpenSSH).

Basically, you should expect that the server may possess a collection of different keys, one for each supported public key algorithm (RSA, DSA, ECDSA). Depending on the negotiated public key algorithm, different key might be returned. Therefore it makes sense to be prepared to storing several keys belonging to the same server, and check the key algorithm when validating the server key. If the algorithm of the received key doesn't match that of the saved key, the key should be considered as new and not changed.

Posted: 08/06/2015 16:38:46
by Zoë Peterson (Priority Standard support level)
Joined: 05/24/2007
Posts: 23

Thanks Ken, I've almost got it.

I'm getting tripped up on the TSSHPublicKeyAlgorithm constants though, since there are so many of them (4 RSA, 4 DSS, 13 ECDSA). Do I need to potentially save 21 different keys for a particular server, or can I save a single RSA key, a single DSS key, and a single ECDSA key? Will SSH_PK_DSS return the same key as SSH_PK_PGP_SIGN_DSS, for example? I noticed if I save the ECDSA key I'm getting in OpenSSH format it has "ecdsa-sha2-nistp256" at the start, so I assume not, but I've only seen that, "ssh-dss", and "ssh-rsa" so far.
Posted: 08/06/2015 17:36:58
by Ken Ivanov (Team)


Unless you deal with a really exotic configuration, it is only about three algorithms, the ones represented by ALGORITHM_RSA, ALGORITHM_DSS and ALGORITHM_ECDSA constants from SBSSHKeyStorage unit/namespace (check the TElSSHKey.Algorithm property to get the algorithm of a particular key). The TSSHPublicKeyAlgorithm type you referenced corresponds to the public key algorithm used during session negotiation, which is more specific than that of the key (e.g., as you've correctly assumed, the same DSS key is likely to be used for SSH_PK_DSS, SSH_PK_PGP_SIGN_DSS and SSH_PK_X509_SIGN_DSS algorithms). A typical SSH server supports SSH_PK_DSS, SSH_PK_RSA and one of the SSH_PK_ECDSA algorithms and has a keypair for each of them. SSH_PK_X509_SIGN_xxx, SSH_PK_SPKI_SIGN_xxx and SSH_PK_PGP_SIGN_xxx are quite exotic algorithms and can be rarely seen these days.

It is a good idea to follow the technique employed by a majority of client-side SSH applications and maintain a list of vectors (server_address, key_algorithm, key_fingerprint), each representing a trusted SSH endpoint. Whenever you connect to a server, you iterate over the list looking for the (server_address, key_algorithm) sub-vector, taking key_algorithm from the TElSSHKey object passed to the OnKeyValidate event. If the vector was found but the key_fingerprint values don't match, it is a signal that the key had changed (or the server had been substituted). If the vector was not found (meaning that you didn't have a chance to connect to this server with the same public key algorithm in the past), the authentication process should be treated as new and the user should be asked to confirm the identity of the server.




Topic viewed 2055 times

Number of guests: 1, registered members: 0, in total hidden: 0


Back to top

As of July 15, 2016 EldoS business operates as a division of /n software, inc. For more information, please read the announcement.

Got it!