The main question is why use Telnet when ssh is available. Some people mentioned routers, maybe that is why. But I would think in this day and age routers would now use ssh.

I do remember reading a long time ago telnet does/can support encryption. But when I looked at the systems I have access to, the manuals have no mention of that.

▲

skissane 2 hours ago | parent | next [-]

The biggest remaining production use of telnet is IBM mainframe and midrange systems. tn3270 which is a telnet extension implementing support for 3270 block mode terminal data streams is still in widespread use, and there is also tn5250 which does the same for 5250 terminals (used on IBM i / AS/400)

This use case is perfectly secure, because IBM mainframe/midrange telnet servers support telnet-over-TLS, and that’s what people run in production

For connecting to mainframes, SSH has no real advantage over TLS, and its major disadvantage is that there is no standardised way to transmit 3270/5250 data streams over it

But people looking for telnet traffic over the public Internet probably won’t even notice this, because they aren’t looking for telnet over TLS - which is difficult to distinguish from whatever else over TLS - and because almost all of it goes over VPNs not the public Internet

	▲	RupertSalt 2 hours ago \| parent [-]
		This is, as far as I know, a completely accurate and factual take. It is also nearly irrelevant. The two entities which have reported on this event are looking for tcp traffic on port 23, not TELNET protocol traffic. So indeed, as you say, if they are tunneled in VPN, or encapsulated or using an alternate port, tn3270 traffic will not be detect on port 23/tcp. Telnet over TLS is assigned to port 992, so any RFC-compliant implementation would be found there, and irrelevant, again, to the telnetd CVE reported this year. There are two facets to January's incident: the vulnerability in the GNU implementation of telnetd, and the purported, widespread blocking of port 23. The original report went out because of the coincidence they perceived there, and especially because the latter preceded the disclosure of the vulnerability! Mainframe tn3270 servers would not be subject to this vulnerability. If there had been a port filter in place, it only would've tripped-up the mainframes that still used port 23, which is evidently optional, and it says here that many admins want to keep AIX's telnetd bound to port 23 anyway. So it is good to know that TELNET protocol, and its extensions, are alive and well. We may not actually know how many clients and servers implement the protocol itself, since MUDs made this a routine thing, but certainly the deployment of IBM systems is formidable, considering the sheer mass of the iron in their rack mounts.

▲

harrall 2 hours ago | parent | prev | next [-]

You can wrap any TCP protocol in TLS which means every TCP protocol supports encryption, Telnet included. The app (and server) simply need to wrap their connections in TLS, which is trivial in many programming ecosystems.

And IMO, X.509 (used in TLS) is virtually superior over SSH’s bespoke certificate format in every way. You get both regular certificate pinning (like what SSH uses now) AND full certificate authority chains (if you want).

The main downside is that X.509 is more complex.

	▲	yjftsjthsd-h 2 hours ago \| parent [-]
		> You get both regular certificate pinning (like what SSH uses now) AND full certificate authority chains (if you want). It doesn't do full chains, but SSH does have certificate authorities. I agree that the lack of intermediate CAs is a limitation (a CA can only sign a leaf node public key directly), but it's still super useful.

▲

shevy-java 3 hours ago | parent | prev | next [-]

I had a similar question. I use ssh usually these days. Telnet has one thing going for itself though: simplicity.

▲

Nextgrid 6 hours ago | parent | prev | next [-]

SSH without proper key management offers marginal benefits compared to telnet.

▲

Quarrel 6 hours ago | parent | next [-]

However bad your key management is, unless you're on an older ssh that will let you choose to use the "None" cipher, you're still better off than telnet!

	▲	signalblur 3 hours ago \| parent [-]
		Right? It doesn’t even make sense - on any actively updated ssh agent you’d have to go out of your way. Also - SSH offers more than just encryption, but also data integrity - you can modify / manipulate a telnet session in ways you just can’t via SSH

▲

gzread 6 hours ago | parent | prev [-]

[dead]

▲

drum55 7 hours ago | parent | prev | next [-]

Probably because ssh ciphers change, telnet doesn’t, and you’re not really supposed to be internet exposing those interfaces anyway.

▲

themafia 6 hours ago | parent | prev [-]

Why use ssh when wireguard is available?

	▲	yjftsjthsd-h 2 hours ago \| parent \| next [-]
		Because I want to login to my user account without sending a password over the wire. If telnet can use keypairs to authenticate users then I guess I don't mind that as a solution, but I haven't heard of it? Also I do care about per-user auth because some of us still work in environments where servers have multiple users.
	▲	01HNNWZ0MV43FF 6 hours ago \| parent \| prev [-]
		So I don't need root permission or kernel networking stuff setup. (I do run Wireguard, it just feels like sometimes a VPN is a sledgehammer to solve a port forwarding problem)