Hi Raphaël,
The HostKey is the server's (in this case, your 250's) key pair. When the connection is first established, the server sends its public key to the client. The client creates a "shared secret", and uses the server's public key to encrypt it, and then returns this to the server. Now both client & server know this shared secret - the client because it created it, the server because it could use its private key to decrypt it - but for a third-party attacker, neither is true, so it doesn't have the shared secret.
The shared secret is then used as the password for a much more efficient cipher (eg AES).
For this to work, the client needs to be able to trust that the key it received from the server, really came from the server. For SSL/TLS, this is done by signing the key using another key the client already knows and trusts (a CA). This is actually possible in some ssh implementations too, but more typically we just compare the key against a copy we already have.
The first time you connect, your client doesn't already have a copy - so you'll be presented with the key's "fingerprint". This is just a cryptographic hash of the public key, to make this comparison easier for a human to make. In the web interface of the 250 (Configurating->Network->Console->SSH Host Key), this is shown as an MD5 hash. Many clients now prefer sha256 by default, but you can usually ask them to show MD5 also in order to make this comparison (eg, for openssh this would be ssh -o FingerprintHash=md5 user@host..).
Once you accept that you trust this key, the public key is saved to speed this up in future connections (eg, in openssh this is the known_hosts file; the long string on each line is a public key encoded with base64). Most implementations store the whole key rather than the fingerprint - it prevents collision attacks, and saves having to hash it every time - at the low cost of using a few more bytes on disk.
To bring this back to the 250; if the client connects and receives a key it doesn't trust, and especially so when the key has changed, a well-behaved ssh client will stop and inform you something unusual has happened. This is the correct behaviour, but can be a real nuisance if you've had to replace or reset the card for perfectly innocent reasons - especially if ssh is being used for automations where this stop isn't immediately visible. So we provide a mechanism to replace this key - so you can install your own, and if you ever need to reset or replace the card, you can install the same key again to quickly and easily re-establish this trust relationship for all clients.
This is all a standard (and mandatory) part of any ssh implementation - but because it's so rarely interacted with, it's easily forgotten. Most people are used to dealing with their own user ssh keys, and assume that's the keys they're looking at - as Gavan said, at this time we don't support the user-key mechanism.
