Do Users Verify SSH Keys? (2011) [pdf]

>TLS verifies that the URL matches cert through the chain of trust,

I think you need to point out that TLS utilizes the browsers cert store for that chain of trust. If a bad actor acquires an entity that has a trusted cert, or your cert store is compromised, that embedded cert store is almost entirely useless which has happened on more than one occassion (Chinese government and Symantec most recently).

https://expeditedsecurity.com/blog/control-the-ssl-cas-your-...

This is typically caught pretty quickly but there's almost nothing a user can do to defend against a chain of trust attack. With SSH, while nobody does it, at least you have the ability to protect yourself.

in SSH, it's a two-way handshake, the client ordering the coffee also gets a cert to prove their identity.

In browser land, the client browser doesn't get a cert to prove their identity, it's one-way only.

Certainly TLS supports client certs, browsers(at least some) technically even implement a version, but the UX is SOOOO horrible that nobody uses it. Some people have tried, the only people that have ever seen any success with client side authentication certificates over a web browser are webauthn/passkeys and the US Military(their ID cards have a cert in them).

webauthn/passkeys are not fully baked yet, so time will tell if they will actually be a success, but so far their usage is growing.

My corporate SFTP server that became mandated to use several years ago presented multiple keys, apparently because it was on DNS round robin.

My attempts to convince them to use the same key came to naught, so instead I use one of the IP addresses.

I could alternately erase the known hosts entry on each transfer. That would probably have been preferable.

I also got a shell on it when I attempted ssh, so you can guess the care that is taken with it.

They might be able to spoof your DNS, for example if you're using their Wi-Fi, so you get the wrong IP address for the right hostname, but not your mail server's SSL. You could pass the host key fingerprint across an existing secure connection, such as in email or with ssh to a host that you already have the fingerprint of.

I'll be honest, I have never spent effort on a host key that had changed unexpectedly, and at least a few have.

Server should publish their key fingerprint to at least the authorized personal of the group. So people know if the server they are connecting to is actually that server.

We need a new protocol, where installing the OS of a new machine automatically installs a trusted key from an inserted USB drive, so that the machine automatically becomes part of the "enclave".

Or something like that.

> I struggle to see a scenario in which a bad actor is able to give me the address of a bad machine, yet not be able to trick me into their host key being the correct one.

If you aren't bothering to verify then they do not need to trick you at all.

In DayJob we have a lot of clients send feeds and collect automated exports via SFTP, and a few to whom we operate the other way (us pulling data via SFTP or pushing it to their endpoint). HTTPS based APIs are very common and becoming more so, but SFTP is still big in this area (we offer some HTTPS APIs, few use them instead of SFTP).

One possible exploit route, for a malicious actor playing a long and targetted game, that could affect us:

1. Attacker somehow poisons our DNS, or that of a specific prospective client of ours, sending traffic for sftp.ourname.tld to their server, and has access to our mail.

2. Initially they just forward traffic so key verification works for existing users. They monitor for some time to record host addresses that already access the server, so when they start intervening they can keep just forwarding connections from those addresses, so those users see no warnings (and are unaffected by the hack).

3. When they do start to intercept connections from hosts not already on the list make above instead of forwarding everything, existing users are unaffected¹ but new users coming in from entirely different addresses now go to their server and if they are not verifying the key will happily send information through it², authenticating with the initial user+pass we sent or PKI using the public key they sent, with the malicious server connecting through to ours to complete the transfers.

4. Now wait and collect data as no one realises there is a MitM, and later use any PII or other valuable information for ransom/extortion purposes.

Of course there are ways to mitigate this attack route. For one: source address whitelisting, supported by OpenSSH's key based auth as the acceptable source list can be included with the public key so only specific sources can use that key for auth. But they client would have to make effort to do this, and if they aren't going to make the effort to verify the host key then they aren't going to make other efforts either.

We do have some clients who verify the host properly and/or give us source addresses to limit connections to when they provide a public key, we work with financial institutions who are appropriately paranoid about their data and the data of their customers, some even use PGP for data in transit (and in case it is ever stored where it shouldn't be) for an extra level of paranoia. But most do none of this. Most utterly ignore our strong suggestion that they use keys, or change passwords in case of email breach, instead using the password we mail them before first connection for eternity.

--------

[1] none of our clients are likely to be sending files from dynamic source addresses, at most the source might move around a v4/24 or v6/64, currently I don't think all of them connect from a single IPv4 address, I've had one recently let us know (months in advance) that their source address will be changing.

[2] it can connect to us and send the data

> ...a host key that changes unexpectedly.

Literally happens every single damn day and literally nobody on the face of this earth ever gives a shit.

Host keys are the stupidest idea in the history of computer so-called "security".

Yeah that is my experience. Users don't understand public key cryptography. You ask them for their public key and they send you the private one. They use the same key everywhere. They don't understand the difference between a host key and a login key. Ask them to do anything with their authorized_keys file and your next ticket will be "I'm locked out of my system."

They do understand passwords, and most can manage an SMS code as a second factor. That's about the limit of what you can count on.

Or you can use SSH certificates, where you work on the basis that if the host key is signed by the correct CA then it's legit. No more tofu required beyond need to trust whatever source you got your CA's public key from.

Also in compliance with Betteridge's law of headlines: "Any headline that ends in a question mark can be answered by the word no."

It's only for the first connection, and it's very rare that targets are valuable on the first connection.

On the other hand, we know of at least two suppliers of software that run with elevated access everywhere (including the dev side of every advanced military) that have been breached by unknown parties for years. The most likely explanation, by far, is that the sky only didn't fall yet because nobody wants it to. And that leaves us vulnerable to somebody suddenly wanting it.

nobody robbed my house in years. i still lock the door.

it's so banal to check host keys.