0

I'm updating multiple Ubuntu systems to respond to Update your Bitbucket Cloud SSH Host Keys. tl;dr: Bitbucket updated their SSH keys, so the clients must update their .ssh/known_hosts accordingly.

At first, I tried to remove the old entries like this:

ssh-keygen -R bitbucket.org

Unfortunately, this didn't work, because .ssh/known_hosts has hashes "related" to bitbucket.org too, and those are not removed. I say "related" because these entries are not just hashed versions of bitbucket.org (ssh-keygen -R would remove those hashes too), but are hashes of the IP addresses of bitbucket.org, such as 2406:da00:ff00::22cd:e0db.

This is already very puzzling to me: I am 100% positive that the system have ALWAYS contacted bitbucket.org via its domain name and NEVER using its IP address explicitly.

Anyway: if I ssh-keygen -R 2406:da00:ff00::22cd:e0db the hashed entry is removed, but bitbucket.org resolves to a wide range of IPv4 and IPv6 addresses, and I cannot know which one(s) are/are not hashed by every system of my list.

OK, so I decided to just truncate (echo > .ssh/known_hosts) the files and add bitbucket.org to the list via curl https://bitbucket.org/site/ssh > .ssh/known_hosts. It worked, but as soon as I try to use it... a new entry is created:

|1|9kAE7U7gEPwOs5jNQC3eMZY4hMw=|4GlyuBNqCjVq3Lk+SyBTGDed+8U= ecdsa-sha2-nistp256 AAAAE2VjZHNhL....

This is the hashed version of 2406:da00:ff00::22cd:e0db, the IPv6 address resolved from bitbucket.org, and the key is exactly the same I already added for bitbucket.org!

It's alright for now, but this means that the next time a key rotation happens (from GitHub, GitLab or one of the other provider I use, maybe?) I will have to truncate the file again!

So, the questions are: why are the IP address related to the hostname hashed? Can I prevent it? Is it possible to -R them all based on the associated hostname?

Dr. Gianluigi Zane Zanettini
  • 2,010
  • 3
  • 32
  • 61

1 Answers1

0

Why are the IP addresses of the SSH host I connect to being added to my .ssh/known_hosts?

That's because the Internet, ultimately (in a sense), operates via IP addresses and not host names. On first connection, you can imagine that SSH associates the hostname to the IP address, and records those two into known_hosts. Later on, if attempt to connect via IP address directly (because you've manually resolved the IP address and do ssh 2406:da00:ff00::22cd:e0db), it'll still work.

Furthermore, if your ssh client suddenly gets a response from the server side presenting a different fingerprint representing its own identity (either via hostname or [possibly multiple] IP address), then, it's a sign that there's been some kind of security compromise and you should investigate further.

BitBucket took proactive action to replace their server's "host key" (ie: fingerprint) because of a security leak. Folks using the old ones will start to fail when trying to connect to the legitimate servers, due to a mismatch: known_hosts would contain a registration of the old keys, but the servers are offering different keys on connection. Ultimately, they widely publicized their new, authentic keys and you'll want to manually compare them or load them into your known_hosts files, and get rid of the offending old keys.

Why are the IP addresses related to hostnames hashed? Can I prevent it.

The HashKnownHosts setting within ~/.ssh/config (see https://www.ssh.com/academy/ssh/config) will often default to yes. It's a security feature - if some bad actor gets access to your known_hosts file, they at least won't be able to directly point to either a domain name nor an IP address to attempt to authenticate as you using your private keys -- it's assumed that a bad actor who has access to the known_hosts file also has access to your private key files.

You can set that to no if you like, but it's not recommended.

starlocke
  • 3,407
  • 2
  • 25
  • 38