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

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.

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

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

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

Why use ssh when wireguard is available?