How client machine ssh verifies the authenticty of the remote host ?

Here's a simplified explanation using layman's terms and bullets:

  • When your client machine tries to connect to a remote host using SSH for the first time, it needs to verify that it's actually connecting to the correct remote host and not a malicious one pretending to be it.

  • SSH does this by using something called "host keys." These are unique identifiers generated by the remote host and stored on your client machine after the first connection.

  • The first time you connect to a remote host, your SSH client checks if it already has the host key for that remote host. If it doesn't, it will display a warning message like the one you mentioned: "The authenticity of host 'remote-sys (192.168.1.4)' can't be established."

  • You're then prompted to confirm whether you trust the remote host's identity by typing "yes" or "no." This step is crucial because it prevents you from unknowingly connecting to a fake or compromised server.

  • If you trust the remote host, your SSH client will save its host key, and future connections will automatically compare the key presented by the remote host with the one stored on your machine. If they match, the connection proceeds without warnings. If they don't match, you'll receive a warning about a possible security issue.

This process ensures that your SSH connections are secure and that you're always connecting to the correct remote hosts.

It is widely advised to use passwordless authentication to connect to remote server . Instead use public private key method.

Using public-private key authentication is often recommended over password-based authentication for several reasons:

  • Increased security: Public-private key authentication is more secure because it relies on cryptographic keys. The private key, which stays on your local machine, is never transmitted over the network, reducing the risk of interception. This makes it harder for attackers to gain unauthorized access to your server compared to password-based authentication, which relies on a potentially weaker password.

  • No need to expose passwords: With password-based authentication, you have to transmit your password over the network, which can be intercepted by attackers. Public-private key authentication eliminates the need to expose passwords altogether, enhancing security.

  • Convenience: Once set up, public-private key authentication can offer greater convenience. You don't have to type in your password every time you connect to the server; instead, your SSH client uses your private key to authenticate automatically.

  • Easier management: Managing access to your server becomes easier with public-private key authentication. You can revoke access by removing the corresponding public key from the server, without needing to change passwords for multiple users.

Overall, using public-private key authentication is a best practice for securing SSH connections to remote servers.