This seems like a relevant answer to your question: Verifying SSH fingerprint of a public server
In short, the SSH server has a public and private key that are used while establishing a connection from the SSH Client. The server will provide a copy of it's public key to the client where it is presented to the user for verification. The user is then responsible for validating that key with the administrator of the server then accepting the key.
Once accepted, the user will only ever see that again if the key changes. When the key changes, it could be a re-key done on the server by the administrator or via MITM style attack; you would need to re-verify the key with the administrator to see which is which.
There is no 'challenge' as I believe you're trying to put it, as this is just how Public-Key Cryptography works.
EDIT:
An SSH server will auto-generate it's host-keys during installation through the use of the ssh-keygen
application. This typically creates an RSA, DSA, ecdsa or ed25519 key, or some variation there of (depending on configuration).
A client connecting to the server will use ssh-keyscan
to check the fingerprint of the server and present that to you as the user for verification. When you accept that key, it writes it to the ~/.ssh/known_hosts
file to remember it. Every time your ssh client connects that to that server, it reads the fingerprint, checks it in the known_hosts
file and ensures it hasn't changed. If it does, you, the user, are presented with a warning that the key changed and the connection is halted. You must manually delete or alter the key to be able to connect again.
$ ssh-keyscan some.remote.server
some.remote.server ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA8BPNr+Q8cQfU95jfJKIfAH+z0+q03QDeFH1ndeTC3Zf0EDjZOg1OXs+Xiwjgrkq+vcNIA5DPaux3aStrcSa5o1AjgBNKN4rMyaLMW1c5LUnSic2oE7YTGvO1AHL55+Z4rCiEbDHeK2LXwhZifNvqkxf44pKrIe8kCvt89dkRsCria4n5EedGazKxO0mvbHM9JSpg03CiD4B+/afOrZqCJrf5dYcDCmeiBPSn9vjiZzAl2NYj05GVSqoe8KeFQV9n4c4LtWfzSDshvLlypuSfylzhL3euWG6JP8G6HnBohSiSQFk/Y0VFX/4wYshKjN3px0ugYUrucXXv8Sznv6n1Dw==
If you were to open the known_hosts
file on my system, you would see this exact entry in there.
EDIT 2:
Reading the comments, you seem to be stuck on this fingerprint bit. The fingerprint is the Public part of Public-Key Cryptography. You should really go read more about this as I linked before to fully comprehend this concept. In Public-Key Crypto, a Private Key and Public Key are mathematically created simultaneously. This key pair holds a special ability in that anything encrypted by the Private key can ONLY be decrypted by the Public key and anything encrypted by the Public Key can ONLY be decrypted by the Private key. This is asymmetric cyrpto, NOT symmetric crypto (using one key for encrypt/decrypt).
You must also understand how signing works to understand the use of Public-Key crypto. If I write a message in plain text and send it to you, you don't know that I sent it. If instead I write a plain text message and at the bottom I add an encrypted blob which contains a hash of the message and was encrypted using my private key, then my public key can be used to decrypt the blob, the original plain text message can be hashed and compared with the hash I included in the encrypted blob.
This same concept is applied here with SSH. Since only the private key used on the server is capable of working with the public key your client has, you can mathematically prove that they are the same machine.
As mentioned in my comment, it is near impossible to generate two private keys which are an exact match thus providing a duplicate fingerprint. If you could generate a private key which was exactly the same as another server's private key, then yes, you would have the same fingerprint as some other server -- Consider this impossible today.