5

I previously purchased/configured a new Raspberry Pi 4 to run Ubuntu 20.04.1 and Apache. I'm forwarding Port 80 on my AT&T modem to the Raspberry Pi and hosting a few websites with no problems.

I received a new Raspberry Pi today and booted up a new instance of Ubuntu 20.04.1 for the first time. Ubuntu got to the login screen, and while I was getting things set up on my laptop to log in via SSH, my Raspberry Pi suddenly had a chunk of output on the terminal.

I recognize it as something corresponding to public keys, since I plan on adding my own public key for SSH logins. That seemed a bit suspicious to me, as I don't recollect that happening when I set up the original Raspberry Pi. I removed port forwarding from my modem while I wiped the SD card clean and booted up Ubuntu anew, only for the same issue to arise. Is my Raspberry Pi being hacked? Is some external entity adding their own SSH key to Ubuntu before I can log in for the very first time?

1

2 Answers 2

18

You can use cloud-init to populate SSH authorized keys. However, the message clearly states:

ci-info: no authorized SSH key fingerprints found for user ubuntu

The fingerprints shown are for host keys, presented by the system to clients.

12

The keys in your linked image are host keys. These are not your private login key.

If we use SSL terms the host key is a bit like the SSL key in your web server. It's private and it's necessary but it's not recommended to share them between hosts so the first boot generates on on the host for you that should be unique to the host. A corresponding public key is also generated at the same time and that's the fingerprints you see there.

SSH supports several different key formats - that's why there's ECDSA, ED25519, RSA, DSA there. You can disable RSA and DSA in the /etc/ssh/ssh_config and then remove those keys if you only plan to use modern SSH clients to access it.

When you first connect to the SSH server it will send the public key(s) to your client. The client will pick the most secure it supports (and is configured to allow) from the ones presented. It will then present the fingerprint of the public key it selected. Keep your image handy and you can verify that is the fingerprint your client shows you. You are asked to verify that it really is the fingerprint for the host. The fingerprint is cached in the known_hosts file so it doesn't need to confirm with you the next time. This is basically the handraulic equivalent of your web browser checking against the CA-issued certificate and showing a padlock.

After that it will continue to select that particular public key for every new session and it will test the fingerprint against its cache. You won't be prompted again unless the fingerprint changes. You will be prompted if it changes.

Again, none of this has to do with your login keys. Nobody else can log in without your password. You will still need your password to log in until you've put your public login key in the authorized_keys file.

1
  • 2
    and in theory, you should ring up the known-to-you person sitting in front of the terminal of the intended remote server, have them read the fingerprint of their host key to you, and you continue your ssh session only if the fingerprints match. This whole protocol is to protect you against a man in the middle impersonating the target host. -- In practice, most people are happy with Trust On First Use and hit enter right away, but you definitely should then be worried if you are presented the question for the same host at a later time Sep 2, 2020 at 13:03

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .