When is executed
ssh -i id_rsa_something remoteuser@192.168.1.2 appears:
The authenticity of host '192.168.1.2 (192.168.1.2)' can't be established. ECDSA key fingerprint is SHA256:ABCABC [fixed/changed]. Are you sure you want to continue connecting (yes/no)? If I write yes I can get access to the remote server through SSH. So until here the SSH configuration for remote connections works as expected. Furthermore in the .ssh/known_hosts file, in the client, was added:
192.168.1.2 ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNo... So the client knows through the .ssh/known_hosts file that has a trusted server and in the server side through the .ssh/authorized_keys file exists a copy of the public key of the client. Until here the security connection can be established in peace between the client and server.
I thought that it is the unique logical approach to establish a connection between the client and server (lets call this the first approach). I mean, generate keys, copy the public key to the server and finally do the connection as the first command shared (even with SSH Agent running or not).
Now, I did a research in StackExchange branches about how to delete a fingerprint in the client side, it through the ssh-agent -R hostname command that affects the .ssh/known_hosts file and generates the known_hosts.old file and works, but in the solutions posted appears how extra information many times the ssh-keyscan to add the fingerprint of the host in the .ssh/known_hosts file - I did a research about that, and the tutorials only teach how to use - I couldn't find a solid reason about when would be mandatory use ssh-keyscan over the first approach
1 Answer
Results of adding the host key to the known_hosts explicitly using ssh-keyscan or by connecting using ssh are technically the same.
Though ssh-keyscan does not really give you a chance to verify that the host key is valid. So you would have to ex-post check the contents of the known_hosts, eventually removing the key if it turns out that it is key of a malicious server. Also known_hosts contains a full key, which you can hardly verify. On the contrary the ssh shows you a fingerprint of the host key, which is easier to verify.
