[derefr]

No, I was talking about two separate time periods. Sysadmins were defining IPSec transports to protect port 23 traffic between mainframes and their terminals for years before SSH appeared. Allowing Telnet sessions to traverse the public Internet was one of the original motivations for IPSec.

The original point of SSH was that it didn't expect the client and the server to be part of the same administrative domain—i.e. it didn't expect a sysadmin to have been involved in advance to pair the devices and define a tunnel. This is why SSH's auth didn't, for the longest time, support any kind of centralized certificate-based PKI: it was for the cases where there wasn't a central authority in common, but rather just two peers that happened to want to talk securely—perhaps without the consent of their respective sysadmins; perhaps even despite the policies of their respective sysadmins.

SSH's "on the spot, look at my keys" auth has become so ubiquitous that sysadmins seem to have forgotten that, most of the time, they do control the administrative domain both devices are under, and can in fact just pair them using e.g. client certificates issued by a private X.509 CA. Fingerprint-based auth should be seen as a last resort, not a first resort; and, likewise, Telnet shouldn't be seen as a last resort, but rather a core tool serving a core purpose in a layered design: enhancing a "local-equivalent" (LAN or VPN) IP link into being a PTY session, upon which any number of things can be run. (For example, "dial-in" MUDs, of which a number still exist.)