Validate the key sent by the server
Unlike X.509 public key infrastructure and TLS, SSH uses a flat key scheme with no trust hierarchy (with extremely rare exceptions where X.509-based keys are used for authentication). The keys are therefore checked by comparing the key received from the server during an SSH negotiation to a cached copy or fingerprint of the trusted copy of the key communicated via different means (e.g. by confirming the hash of the key in advance by e-mail, over the phone, or via a secure web site).
When your SecureBlackbox SSH components receives a key from the server, it reports it via OnKeyValidate event. It is your responsibility, as a component user, to handle this event and perform key validation inside the handler.
(VERY) IMPORTANT: neglecting correct implementation of the validation routine, particularly by implementing it in 'by-pass' way by forcefully setting Validate to true without any checks, is extremely dangerous and will compromise the whole security of the SSH system you are building.
Key validation normally involves maintaining a local database of 'known' keys. In the simplest case this may be fulfilled by a CSV file. Each record should contain the server record (IP address and/or domain name) and the key record. The latter should at least contain some data which could serve as nearly-unique identifier of the key (SHA1 fingerprint is OK), but storing the whole key together with its algorithm might be a better option.
Note that a server might possess several keys, so your database format should be ready to take several records belonging to the same server.
When you receive a fresh server key in the OnKeyValidate handler, you must perform the following steps:
Note that this scenario might take place with a genuine server if a different public key algorithm was negotiated and a different key returned (see above). You might consider to design the UI of this step carefully so that your users got the right impression from this step and could take an educated action.
If key confirmation routine was successful, add new key record to the database, set Validate to true and exit the routine. Otherwise, set it to false, and the components will terminate the connection for you.
You will find some TElSSHKey properties useful for the implementation of key validation:
Note: SSH servers often maintain several different private keys for different algorithms they support (e.g. RSA, DSS, ECDSA). If you change the set of public key algorithms supported locally, or change the algorithms' priorities, you might end up receiving a different public key not matching your local copy.
Note. Microsoft changed their implementation of .NET quick sort algorithm between .NET version 2 and 4.5, so you might end up receiving different keys even when migrating your project from .NET 2.0 to .NET 4.5 (and with no other changes in place!) This is because SSH components use sorting algorithms internally to sort algorithms by their priorities, and algorithms having the same priorities (e.g. RSA and DSS) might come in different order due to the algorithm changes.