Dave,
When you try to login to a server using PuTTY, for the first time from a Linux machine, you're sure to get the following dialog box:
# ssh
user@example.com
Host key not found from the list of known hosts.
Are you sure you want to continue connecting (yes/no)? yes
Host 'example.com' added to the list of known hosts.
user@example.com's password: *******
The login will continue just as it would have if a session was created using rlogin or telnet. SSH utilizes a key fingerprint system for verifying the authenticity of the server when the client connects. The user is prompted to enter yes only when connecting for the first time. Future attempts to login are all verified against the saved fingerprint key. The SSH client will alert you if the saved fingerprint differs from the received fingerprint on future login attempts. The fingerprints are saved in
~/.ssh/known_hosts, or
~/.ssh/known_hosts2 for SSH v2 fingerprints.
As you're using a Windows machine to connect to your server, in that case all the
Ssh Host Keys or
fingerprints are stored in the following location in the registry:
[HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\SshHo stKeys]
Once you click on 'Yes' an entry of new Ssh Host Keys or fingerprint is created & stored in the above mentioned location every time you login for the first time.
By default, recent versions of the SSH servers only accept SSH v2 connections. The client will use version 2 if possible and will fall back to version 1. The client can also be forced to use one or the other by passing it the -1 or -2 for version 1 or version 2, respectively. The version 1 compatibility is maintained in the client for backwards compatibility with older versions.
Regarding the
Man-in-the-Middle attack you mentioned, if the first connection and host key exchange between a client [you] and a particular host [your
VPS Hosting] is compromised, the MITM attack fools both the client and server into thinking that they are communicating directly with one another when, in fact, an attacker is actually intercepting all traffic between the two. Secure Shell protects against MITM attacks through server host authentication, unless the host itself has been compromised.
In the end, I'd like to tell you that
'Nothing is 100% secure', & someone has rightly said that
"You cannot keep things absolutely safe, the lesson to be learned here is everything can be hacked into; it's just a matter of time." The best way to combat this is with encryption. Encryption works when two people communicating have special keys, or passwords. Encrypted data transaction is "scrambled," and the only way for anyone else to read it is to have the "matching" key. RSA encryption being the best between them, or either way use PuTTYGen to generates an RSA public/private key pair.
Please refer this link for more details:
cs.uwaterloo.ca/cscf/howto/ssh/public_key