8

I've gotten my first Raspberry Pi to experiment with. While I learn about it, I'm also experimenting with different OSes, specifically the default with the GUI and the Lite without.

I've got them both set up to accept SSH connections, but every time I swap the cards, I have to go into /.ssh/known_hosts (on macOS) and remove the fingerprint entry for the other card because, probably given the single MAC address for computer, the router is giving it the same IP number.

It's not a huge problem, and hopefully soon I'll be swapping the cards much less, but I'd like to know if there's any way say to SSH, "I don't ever care of the fingerprint of this IP address changes," or perhaps some way to store two fingerprints for the IP address?

4 Answers 4

12

The public host keys from your machines will be automatically inserted in ~/.ssh/known_hosts (at least the first time you connect). We can find info on that file in the sshd(8) man page:

It is permissible (but not recommended) to have several lines or different host keys for the same names.

So you can have multiple lines for your local known_hosts file with the same hostname/IP, but unique keys. The connection process won't do this for you, you'll have to manually manipulate it to put the keys for each of the host keys from each of the cards.

known_hosts:

myhost,1.2.3.4 ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYT...YjdB=
myhost,1.2.3.4 ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYT...I8Bg=

Sample session

$ ssh -vvv myhost
...
debug3: hostkeys_foreach: reading file ".ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file .ssh/known_hosts:1
debug3: record_hostkey: found key type ECDSA in file .ssh/known_hosts:2
debug3: load_hostkeys: loaded 2 keys from myhost.mydomain
debug3: hostkeys_foreach: reading file ".ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file .ssh/known_hosts:1
debug3: record_hostkey: found key type ECDSA in file .ssh/known_hosts:2
debug3: load_hostkeys: loaded 2 keys from 1.2.3.4
debug1: Host 'myhost.mydomain' is known and matches the ECDSA host key.
debug1: Found key in .ssh/known_hosts:2

Another thing to consider is to set each of the installations to have a unique IP address rather than pull it from DHCP. Then you'd have a 1:1 relationship between the OS and the IP.

5
  • You're correct regarding config. I've edited the question. Thanks for point that out.
    – Chuck
    Commented Nov 8, 2021 at 19:45
  • 2
    The public keys in ~/.ssh/known_hosts are used to identify external hosts your Pi has connected to. They DO NOT identify the Pi. The host identification used on a system connected to the Pi is a thumbnail derived from /etc/ssh on the Pi. This approach works well on conventional computers, where the host keys are stored on non-removable storage. Unfortunately Pi users swap SD Cards, and thus change the host identity. There are 2 ways to avoid this; ignore host key checking or ensure all SD Cards have the same host key.
    – Milliways
    Commented Nov 8, 2021 at 22:48
  • I'm not sure I understand your comment. In this case the servers (what you call external hosts) are pi's with removable cards. This method allows you to associate multiple host identities with a single name or IP address.
    – BowlOfRed
    Commented Nov 8, 2021 at 22:55
  • 2
    @BowlOfRed the OP is connecting from macOS to PI; The content of known_hosts is not involved - it is the known_hosts file on the Mac. If you connect to the same Pi with a different host the same IP will be used, with different host ID, causing the Mac to object.
    – Milliways
    Commented Nov 8, 2021 at 22:57
  • 2
    @Milliways: Yes, and you can stop the Mac from objecting by adding both public keys to ~/.ssh/known_hosts on the Mac, just as this answer describes. Commented Nov 9, 2021 at 0:40
10

I have ~20 SD Cards with many OS, all of which can be interchanged between my multiple Pi.

The host identification used on a system connected to the Pi is a thumbnail derived from /etc/ssh on the Pi.

You CAN ignore host keys, but it is easier to ensure all SD Cards are using the same keys.

1. On working Pi backup ssh keys

    #PBackup ssh host keys & config (script sshBackup)
    # 2021-08-18
    cd /etc/ssh

    #PBackup ssh host keys
    sudo tar czf /home/pi/SshKeys.tgz *key *.pub moduli

    #PBackup ssh config
    cd /etc/ssh
    sudo tar czf /home/pi/SshConf.tgz *config

5 Restore ssh keys
    #Replace ssh host keys  (script sshReplace)
    # 2021-08-18
    cd /etc/ssh
    sudo tar xzf /home/pi/SshKeys.tgz

If you do decide to ignore host keys you can edit ~/.ssh/config on the Mac to only ignore keys on your home private network which is more secure.

A typical for use on a Mac would be:-

Host 10.1.*.*
   StrictHostKeyChecking no
   UseKeychain yes
   BatchMode yes
   PasswordAuthentication yes
1
  • Or you can give them all different keys, but add all of the fingerprints to the known_hosts on the Mac. This has the advantage that, if one of the SD cards (and hence its private key) is lost, you can just remove that one from your known_hosts, rather than having to change the key on all of your SD cards.
    – psmears
    Commented Nov 10, 2021 at 9:48
7

Yes, there is a way to accept a new fingerprint:

ssh -o StrictHostKeyChecking=no <host or IP>

Only use this command when you expect the host fingerprint to change, using it every time essentially gives up security.

Documentation

9
  • 3
    That's not accepting new fingerprints, it's ignoring them.
    – chepner
    Commented Nov 8, 2021 at 12:27
  • My point is, it believes whatever the remote host tells it. You may as well not even use host keys in that case.
    – chepner
    Commented Nov 8, 2021 at 18:05
  • @DmitryGrigoryev you know, you can copy the links of the headings of the Docs which have dots as a footer and paste it: so we only read the relevant part. Commented Nov 9, 2021 at 8:09
  • @chepner You shouldn't use this command every single time. You use it once, when you know the host key changed, to get it updated. Next time you connect with a normal ssh host command and key checking works as planned. This is just as secure as accepting a key for a new host without checking every byte of it, which is what 99% of users do anyway. Commented Nov 9, 2021 at 11:09
  • @VScode_fanboy Yes, I know that. It's also trivial to search for "StrictHostKeyChecking" within a page, so I didn't think it would be a problem for you. And besides, everything the OP needs to know is in the answer itself, the docs are extra reading for those who are interested. Commented Nov 9, 2021 at 11:12
4

I have to go into /.ssh/config (on macOS) and remove the fingerprint entry for the other card because,

I suppose you mean known_hosts, instead of config. You don't have to go there manually to remove the lines, ssh-keygen has a subcommand for it:

$ ssh-keygen -R somehost
# Host somehost found: line 1
/Users/me/.ssh/known_hosts updated.
Original contents retained as /Users/me/.ssh/known_hosts.old

That's especially useful with hashed known hosts files, where finding the correct line manually is a chore. Those have been in use for a while now, though the utilities shipped with macOS, might not be too recent.

"I don't ever care of the fingerprint of this IP address changes,"

You should be able to do that too. In .ssh/config, the StrictHostKeyChecking option controls checking the fingerprints, and the Host statement can be used to apply it to just one host:

Host hostname-or-ip
StrictHostKeyChecking no

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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