> If someone had wanted to make telnet encrypted, they would just have had to implement the standard telnet protocol and add another option in the protocol […]

    This document describes a the telnet encryption option as a generic
    method of providing data confidentiality services for the telnet data
    stream.  While this document summarizes currently utilized encryption
    types and codes, it does not define a specific encryption algorithm.
    Separate documents are to be published defining implementations of
    this option for each encryption algorithm.

* https://datatracker.ietf.org/doc/html/rfc2946

So I did recall correctly, then.

> Speaking as someone who was actually using Unix systems when this happened, the "ssh" command was replacing the rsh command,

A different data point: I was also a Unix sysadmin at the time (thought just out of school) and for me ssh replaced telnet and ftp. I never used rsh, rlogin, and rcp except when testing exploits.

In my experience, telnet and FTP were used when accessing external resources; when wandering around the local menagerie of machinery, rsh, rlogin and rcp were predominant.

Telnet predates UNIX and came from the late 60s; rsh/rlogin were introduced by BSD in the 80s. So if you were in a BSD-derived system, you might have used rsh/rlogin, but otherwise telnet was the standard. Telnet was also cross-platform; I first used it on VMS.

Ditto, I had been doing sysadmin as my job for a few years in 1995 and as a component of my job or as a hobby for ~5 years before that. I was decidedly a telnet/ftp guy before ssh, and dabbled a little with "ssltelnet". I mostly avoided rsh and family because I didn't love the security model.

SSH was a fantastic improvement at the time, though the whole licensing model interfered with my use for the first several years.

My experience as well.

Much depends on whether your systems were running BSD-style RPC services.

He included the letter he wrote to IANA so, unless you are calling fraud, it is actual history rather than revisionist history.

In that letter he says: “It provides major improvements in security and functionality over existing telnet and rlogin protocols”.

So, while you are correct about rsh, it seems totally fair ( and likely just correct ) for him to say he chose port 22 for its proximity to telnet. Also, since SSH includes SFTP, what he says about FTP checks out as well.

The story is about “why 22” and telnet answers that question better than rsh does. I guess if the question was “why ssh”, the details you added would matter more.

Without having any specific information on the matter at hand: revisionist history does not need fabricated facts. Its very possible to revision history by omitting crucial parts. Hence the letters might be genuine and someone revisions history by leaving out other relevant information.

Oh, rsh, your security model was so cute. It runs on port 513. (There is also rexec, port 512, and rcp on port 514. rlogin runs on port 513 along with rsh.)

I think it's a bit unfair to call it revisionist. It's a direct claim by the author of ssh, and out of all the ports numbered 1-255, telnet (23) does come closest in function to ssh. I believe the article is more about how lucky the author got to nestle a port between two other protocols that ssh superseded, rather than the thinking behind the naming of the ssh family of protocols.

Berkeley compute facilities used $rsh and $rlogin .. not clear on the file transfer from the outside. Dial-up modem from a residential phone line in those days, this was before 9600 baud became common for individuals.

ftp on the other hand was more like finger or similar.. going to some external site that was public, or had a login to distribute files.