6

I have a Raspberry Pi and can access it via SSH (authentication via user password) when my laptop is in the same network. Now I want to access it over the internet.

I already set my router to forward the port to my Raspberry Pi and installed fail2ban to (hopefully) make cracking the password via brute force infeasible.

The weird thing is that I get a different key when accessing the Pi over the internet instead of via LAN:

christoph@christoph-laptop-14-04:~$ ssh-keygen -H -F 192.168.1.92
# Host 192.168.1.92 found: line 9 type ECDSA
|1|Zz8zhCYwRu7jKa/bcUTnw/BzGmo=|m2E+0RwiVXcr8lAxbK/W13ZmZUA= ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBAgUNwcHmVBowUoKvi9iLtoKifh/9qKAj6BNfQsYzYuoXtlYEnTUVLn4XpMYJ9+TMwL23ZDnmJuz8noKK3rFrYg=
christoph@christoph-laptop-14-04:~$ ssh-keygen -H -F [my global IP]
# Host 185.5.10.87 found: line 10 type ECDSA
|1|kEE5HDC1uBkqDN3SpQ8yFvwdj0A=|iDaNuB2Y8d3kIFPqFoXjrERRJ/0= ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBAgUNwcHmVBowUoKvi9iLtoKifh/9qKAj6BNfQsYzYuoXtlYEnTUVLn4XpMYJ9+TMwL23ZDnmJuz8noKK3rFrYg=

Everything but the beginning is the same. So why is the beginning different? Is the IP address encoded into this or something like this?

Another thing that confuses me is that when there was a different key before (I'm obviously unable to connect because the key changed but also) I'm shown this:

ECDSA key fingerprint is ed:47:24:c6:4e:c1:ca:99:d9:77:59:8f:01:12:85:cd

I can figure out the one of my laptop via:

ssh-keygen -l -f /etc/ssh/ssh_host_ecdsa_key.pub

and it comes in the same format. But when I ssh into my Pi and execute the same command, the output is:

256 SHA256:Npy6IbI8vDd4V3iCOcIVEsF4j2bsf9vbWcsf1ti8izE root@christoph-pi (ECDSA)

which doesn't seem to have anything to do with ed:47:24:c6:4e:c1:ca:99:d9:77:59:8f:01:12:85:cd.

I first thought that maybe Npy6IbI8vDd4V3iCOcIVEsF4j2bsf9vbWcsf1ti8izE was a base 64 encoding for ed:47:24:c6:4e:c1:ca:99:d9:77:59:8f:01:12:85:cd which seems to be in hex coding with each byte separated from the next one with a colon, but the length of Npy6IbI8vDd4V3iCOcIVEsF4j2bsf9vbWcsf1ti8izE is 43 which isn't an integer multiple of 4, so it's not base64. So what is it?

  • Possible duplicate of Should different versions of SSH give different VisualHostKeys? – Jakuje Mar 31 '16 at 8:44
  • @jakuje That question deals mostly with the changes in Host keys between versions, not when a host key changes due to network changes. I believe this questions is the latter. – Ohnana Mar 31 '16 at 18:32
  • @Ohnana There are at least three problems mixed together in question in no particular order, but the main problem is in the of fingerprints from different openssh versions use different format. Earlier I was too lazy to write separate answer, since I thought one can make things up from my answer there (but it is tied to a bit different use case). I will try to write something. – Jakuje Mar 31 '16 at 18:43
2

The weird thing is that I get a different key when accessing the Pi over the internet instead of via LAN:

Manual page for sshd describes format of your known_hosts file:

SSH_KNOWN_HOSTS FILE FORMAT

Each line in these files contains the following fields: markers (optional), hostnames, [...]. The fields are separated by spaces.

Se we got to the first answer. The first field is hostname, which is obviously different when you connect from outside or from inside, as proposed in your question.

Further we can read

Alternately, hostnames may be stored in a hashed form which hides host names and addresses should the file's contents be disclosed. Hashed hostnames start with a ‘|’ character. Only one hashed hostname may appear on a single line [...]

Yes, your hostnames/ip addresses are hashed.


But when I ssh into my Pi and execute the same command [...]

The new versions are using SHA-256 hashes instead of the obsolete MD5. You can force the new version to generate you the old fingerprint using:

ssh-keygen -l -E md5 -f /etc/ssh/ssh_host_ecdsa_key.pub

Conversion between these two formats are possible, but not useful. Using ssh-keygen directly as I proposed above is advised solution.

You can generate fingerprint from public key stored in your known_hosts file somehow like this:

ssh-keygen -l -f <( ssh-keygen -H -F 192.168.1.92 | tail -n 1 | cut -d" " -f 2,3)
  • If one wants to force the new version to use the old hash, shouldn't they put "md5" there instead of "sha256"? And can I figure out whether the fingerprint is correct before adding the entry to the known hosts file? – UTF-8 Mar 31 '16 at 23:31
  • Yes. It was typo. Fixed now. You can verify it by comparing the fingerprints. – Jakuje Apr 1 '16 at 5:57
  • I added a ssh-keygen command to generate fingerprint from known_hosts file. I hope it will answer your question. – Jakuje Apr 1 '16 at 7:14
  • The command only prints /dev/fd/63 is not a public key file.. I meant something like: I ask the Pi on the console for its fingerprint. Then (when connecting over an insecure channel) I only have to compare the fingerprint it shows me with the one I got from the Pi and can make sure I really am connecting to my Pi. Would this work or do I still need to compare the public key of the Pi with the one it saves to my known hosts file after I accepted the connection? And can I get this public key before saving it to my known hosts file? – UTF-8 Apr 1 '16 at 17:47
  • The first command (ssh-keygen -l -E md5 -f /etc/ssh/ssh_host_ecdsa_key.pub) will give you fingerprint from Pi console and the same fingerprint you see in the prompt while accepting connection, isn't it? Where is the problem? – Jakuje Apr 1 '16 at 17:50
1

The left hand side of the output of ssh-keygen -H -F 192.168.1.92 is the hash of the IP address. If you were to run the command without the -H option you'd get something similar to:

christoph@christoph-laptop-14-04:~$ ssh-keygen -F 192.168.1.92
# Host 192.168.1.92 found: line 9 type ECDSA
192.168.1.92 ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBAgUNwcHmVBowUoKvi9iLtoKifh/9qKAj6BNfQsYzYuoXtlYEnTUVLn4XpMYJ9+TMwL23ZDnmJuz8noKK3rFrYg=

This shows the IP address on the left. When run with the -H option, the command shows a hash of the IP address instead, which will obviously be different for each host.


The output formatting of ssh-keygen -l -f /etc/ssh/ssh_host_ecdsa_key.pub may vary if you are using different versions of ssh-keygen.

My CentOS machine gives the same format as your Raspberry Pi, while my Pi gives the same colon delimited format as your laptop. The actual output values are obviously different because they input to the command are different public keys.

  • Somehow I get exactly the same as with -H: pastebin.com/Fcxswkin Is the AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBAgUNwcHmVBowUoKvi9iLtoKifh/9qKAj6BNfQsYzYuoXtlYEnTUVLn4XpMYJ9+TMwL23ZDnmJuz8noKK3rFrYg= part the public key? Because this is the same whether I access via internet or via lan. Can I figure out whether the fingerprint ed:47:24:c6:4e:c1:ca:99:d9:77:59:8f:01:12:85:cd is correct before adding the key to the known hosts file? It seems like a bad idea to first say "Oh, yeah, it's alright." and then go check whether this is true and if it's not to delete the entry. – UTF-8 Mar 31 '16 at 15:05
  • If you run ss-keygen -H (without the -f option) then it will permanently convert all IP addresses to their hash equivalent in the know_hosts file. Maybe you did this (accidentally) in the past. The hash of the server's public key should be passed to you by some out-of-band method such as talking to the server admin, or publishing it on a secure website etc. – garethTheRed Apr 1 '16 at 6:29

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.