2

I have created 2 key pairs using ssh-keygen, one on the server and one on the client.

I then added the server's public key to the client's $HOME/.ssh/authorized_keys file, and vice-versa.

When I try to ssh from the client to the server, I'm still greeted with the 

The authenticity of host <host> can't be established
ECDSA key fingerprint is SHA256:<hash>

Why does this happen? I would expect in the presence of public keys the authentication of the host could be established. Also I have not created a ECDSA key myself, only RSA ones. Is this a build-in key?

Improve this question

3 Answers 3

Reset to default
3

You're confusing verification of a server with its host key (done by the client) with authentication of a ssh user login (done by the server).

The authenticity of the host is verified on the client with the host key. This should prevent possible MITM attacks pretending to be your server. The host keys are saved on the server in /etc/ssh/ssh_host*key and on the client in ~/.ssh/known_hosts file.

Connecting to a server using ssh -vvv shows this:

debug1: Server host key: ecdsa-sha2-nistp256 SHA256:fYR10r/RKXIzOmJYbgbDi29E10oW7MLjto2plpALaBY
debug3: hostkeys_foreach: reading file "/home/xxxx/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /home/xxxx/.ssh/known_hosts:69
debug3: load_hostkeys: loaded 1 keys from xx.xx.xx.xx
debug1: Host 'xx.xx.xx.xx' is known and matches the ECDSA host key.
  1. Server sends host key
  2. Client searches the key in known_hosts
  3. Client loads and verfies the key

You don't need to manually create the host key, this is done automatically. On the client side you don't need to add the host key manually as this is done on the first connection to a server (You have to type 'yes').

When the host key changes due to new installation of the server you need to remove that key from the known_hosts file, otherwise ssh refuses to connect unless you have the -o StrictHostKeyChecking=no option set which I would not advise to do.

When you added the ssh key from your server to your clients authorized_keys file, you authorize connections from your server to your user on the client which is probably not what you want. I advise you to remove the key on the client side.

Further reading:

Improve this answer
3
  • So the host key is a plaintext string that's send to the client unecrypted during every connection? I assume it does offer a minor indication of spoofing but it's hardly a good enough measure. Up to this point I thought both the server and client authenticated each other and verified their identities using public key cryptography.
    – J. Paparas
    Apr 11, 2019 at 11:52
  • no. It sends you the public key and a proof that it owns the private key. You save the public key.
    – pLumo
    Apr 11, 2019 at 12:01
  • Ok, thanks. I guess I have more reading to do.
    – J. Paparas
    Apr 11, 2019 at 12:45
0

You are receiving this message because of the "ECDSA key fingerprint", not the public RSA key. When you copy the content of the public key file .pub to .ssh/known_hosts manually, fingerprint is not included.

If you look at any other entry in known_hosts in which you already accepted the message:

The authenticity of host '<host>' can't be established.
RSA key fingerprint is SHA256:fingerprint.
Are you sure you want to continue connecting (yes/no)?

you will find a string preceding the type of key (ssh-rsa, ecdsa-sha2-nistp256, etc...). This is the fingerprint, and can be manually calculated with ssh-keygen -lf <public_key_file> (which is located at /etc/ssh/ in your server) or ssh-keygen -l -F <domain_or_ip> from your client.

Furthermore, this message is the result of the option StrictHostKeyChecking. This message is activated by default for security, but can be disabled with ssh -o "StrictHostKeyChecking=no" user@host, making ssh store fingerprints without any message (as I said, not recommended).

This question is somehow related to yours: https://serverfault.com/questions/422869/answer-yes-to-ssh-copy-id-first-time-run-by-script

Improve this answer
-1

You can transfer your client key to your server (you don't need to transfer server key to client) by executing:

ssh-copy-id <your-ssh-server-ip_or_hostname>

After that you can login via keypair by just ssh <your-ssh-server-ip_or_hostname>

EDIT:

And your ecdsa (elliptic curve key) is your server key, that key transfer is automatic. Have your server been reinstalled, thus having a new server key?

you can remove your server key from client by executing:

ssh-keygen -R <your-ssh-server-ip_or_hostname>
Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.