-1

I'm not able to connect to my raspberry pi via ssh likely after wrong password. What can I do to remove the administrator ban?

Here is what it prompts:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
3
  • 2
    Generally the error message tells you exactly what to do to correct this fault. Not Pi specific.
    – joan
    Sep 28, 2020 at 20:00
  • I guess you have reformatted the SD card. This generates a new ID for the Pi - remove the old one from your ssh known hosts and accept this. Nothing to do with a wrong password.
    – user115418
    Sep 28, 2020 at 20:03
  • @Andyroo Although it may be a result of reformatting a card, I don't think it is in most cases, and swapping in the host ID is not necessarily a great fix. If you have a number of devices on a LAN using DHCP, they are prone to ending up with different IP addresses over time -- often enough the address that another device possessed previously. If it's the addresses that are cached (as opposed to the hostname), it becomes tedious.
    – goldilocks
    Sep 28, 2020 at 20:40

1 Answer 1

1

This is because SSH corresponds IP addresses and hostnames to the public key submitted by them on first connect; this information is in (on linux, anyway) ~/.ssh/known_hosts.

If the correspondence is based on a hostname:

[raspberry.pi]:ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNT

And you are using that hostname explicitly to connect, and it belongs to only one remote host you connect to, then you can swap in the new public key as Andyroo suggests -- the easiest way to do that is to just delete the entry in known_hosts on the system you are trying to ssh from, then connect again and the new key will be stored.

If IP addresses are involved directly at all, though, this becomes messy. Presuming you are on a home LAN and aren't super worried about anyone secretly planting a spoof raspberry pi there, you can instead add this to ~/.ssh/config, again on the machine you are connecting from:

# Use a CIDR appropriate to your LAN's range if "192.168..." isn't:
Host 192.168.0.*
StrictHostKeyChecking no
UserKnownHostsFile /dev/null

These are documented in man ssh_config; the first one ditches the check that caused your error, the second prevents the keys from being cached at all.

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