Telnet is used in legacy, IoT, embedded, and low-level industrial hardware. It's also intentionally enabled on devices where automation was written for telnet and it wasn't easy to switch to ssh.

If you investigate most commercial uses of ssh, the security is disabled or ignored. Nobody verifies host keys, and with automation where hosts cycle, you basically have to disable verification as there's no easy way around the host keys constantly changing. Without host key verification, there's kinda no point to the rest.

Even assuming the host keys were verified, the popular ssh conventions are to use either long-lived static keys (and almost nobody puts a password on theirs), or a password. Very few people use SSH with 2FA, and almost no-one uses ephemeral keys (OIDC) or certificates (which many people screw up).

So in terms of how people actually use it, SSH is one of the least secure transport methods. You'd be much more secure by using telnet over an HTTPS websocket with OAuth for login.

▲ taftster 19 hours ago | parent | next [-]

How do you automate, for example, "HTTPS over websocket with OAuth", without providing some kind of hard-coded, static or otherwise persistent authentication credentials to the calling system in some form (either certificate based auth, OAuth credentials, etc.)?

The problem with IoT and embedded secrets isn't really a solved problem, from what I can tell. I'm not sure that OAuth exactly solves the problem here. Though all your comments about SSH (especially host verification) holds true.

Just honestly trying to understand the possible solution space to the IoT problem and automated (non-human) authorization.

	▲	emmelaich 18 hours ago \| parent [-]
		The manufacturer should at least supply certificates, and it could be up to you to ignore or use. It's not much but it's something.

▲ watermelon0 14 hours ago | parent | prev | next [-]

Unless you manage to leak your private host/client SSH keys, this is close to being as secure as it gets.

I'd say that HTTPS (or TLS in general) is more problematic, since you need to trust numerous root CAs in machine/browser store. Sure, you can use certificate pinning, but that has the same issues as SSH host key verification.

	▲	0xbadcafebee 4 hours ago \| parent [-]
		CA compromise is very rare and difficult. There are much easier attacks on TLS than that (notably, attacking insecure validation methods; the problem isn't that CAs aren't secure, it's that validation methods and their dependencies are insecure). Besides, the CAs for TLS only covers transport security; authentication+authorization would be handled securely through OIDC, using temporary sessions and not exposing the true credential, often combined with 2FA. Even you successfully attack a TLS server, two factors, and an active session, it only works once; you have to keep pulling it off to remain inside. Compare that to malware that just copies a developer's ssh private key off the disk (again, almost nobody ever password protects theirs). This just happened recently on a massive scale with the npm attacks. Or intercepts the first connection from a client host and, again, because nobody ever validates keys, injects a false host key, and now they're pwnd indefinitely. Or, again, companies that do not strictly validate host keys, meaning immediate MitM. There's like a dozen ways to compromise SSH. It doesn't have to be that way, but it is that way, because of how people use it.

▲ Fnoord 17 hours ago | parent | prev | next [-]

> Very few people use SSH with 2FA.

PCI DSS, HIPAA, and ISO 27001 each either highly recommend or enforce this.

I wouldn't use a jumphost without it.

▲ ajross 18 hours ago | parent | prev [-]

> 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.