> Nobody verifies host keys,

The known_hosts file is verification of host keys. It's not verification of a host cert, which is a different thing. Most sshd instances are running on ad hoc hardware without the ability to associate them with someone a cert authority would be willing to authenticate.

Basically people running services that need cert-based authentication are already using TLS (or if they're using sshd they've locked it down appropriately). SSH is for your workstation and your RPi and whatnot.

▲ SAI_Peregrinus 16 hours ago | parent | next [-]

SSH certs aren't TLS certs. Totally different format. All SSH CAs are private, you run your own CA to issue certs to devices you want to allow to connect to your server.

	▲	ajross 6 hours ago \| parent [-]
		It's... not about the file format. The point is that a "private" cert is not a "cert" as commonly understood. The important part to a certification authority is the AUTHORITY part, not the data format. Either there is a trusted third party that will promise you are who you say you are, or there is not. With SSH, there is not, nor can there be as it is commonly deployed. So applications that want that have used other protocols and other schemes, very productively.

▲ PhilipRoman 12 hours ago | parent | prev [-]

>>Nobody verifies host keys,

>The known_hosts file is verification of host keys

I think the point was that those devices typically generate host keys dynamically and therefore the host key verification is usually turned off, leaving you just with encryption (which is still better than telnet - at least you're safe against passive adversaries). At least that's what I've seen in practice.

▲ ajross 6 hours ago | parent [-]

Host key verification is a client feature and is on by default. Have you really never gotten the giant warning after a reinstall? That's what that is. SSH is telling you that the server has changed and isn't what you think.

▲ PhilipRoman 4 hours ago | parent [-]

I'm saying that 90% of these setups look like this (or do the equivalent thing manually):

   ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null root@192.168...

They have ssh, but no proper key management

	▲	0xbadcafebee 4 hours ago \| parent \| next [-]
		Exactly. But 'passive encryption' isn't helpful; if you can see the traffic, you can MITM it. Just RST the connection, wait for the reconnect, intercept.
	▲	ajross 4 hours ago \| parent \| prev [-]
		Well, sure. You can turn off host key checking in ssh! But that isn't responsive to a point that (1) host key validation exists in ssh and (2) host key validation is on by default in ssh.