Hacker News Reader

Comment by codetrotter | Hacker News Reader

SSH was a replacement for Telnet. But any weaknesses at the TTY level is orthogonal to that, right?

Unless you mean, having thin clients use SSH as opposed to directly running serial cables throughout a building to VT100 style hardware terminals, and therefore being vulnerable to eavesdropping and hijacking?

But I think when we talk about TTY we mostly don’t refer to that kind of situation.

If someone talks about TTY today, I assume they mean the protocol and kernel interfaces being used. Not any kind of physical VT100 style serial communication terminals.

View on HN

I miss rooms of green and amber screen terminals hooked up via serial cable. As an undergrad I remember figuring out how to escape from some menu to a TTY prompt that I could somehow telnet to anywhere from. Later, I would inherit a fleet of 200 of them spread across 12 branch libraries. I can't remember how it worked except that somehow all the terminals ran into two BSDi boxes in the core room of the central library, and it had been hardened so you could not break out of the menus and telnet to arbitrary places. Over a year I replaced them all with windows machines that ran version of netscape navigator as the shell with an interface that was built in signed javascript. It was the early days of the web, and we had to support over 300 plug ins for different subscriptions we had. The department that ran the campus network didn't want to let me on the network until I could prove to them everything was secure.

SSH was a replacement for RSH, not telnet.

This was on HN two(?) days ago: https://news.ycombinator.com/item?id=39313170

> I wrote the initial version of SSH (Secure Shell) in Spring 1995. It was a time when telnet and FTP were widely used.

> Anyway, I designed SSH to replace both telnet (port 23) and ftp (port 21). Port 22 was free. It was conveniently between the ports for telnet and ftp. I figured having that port number might be one of those small things that would give some aura of credibility. But how could I get that port number? I had never allocated one, but I knew somebody who had allocated a port.

Emphasis mine.

Cheers.

https://docs.oracle.com/cd/E36784_01/html/E36870/ssh-1.html from man page: It is intended to replace rlogin and rsh, and to provide secure encrypted communications between two untrusted hosts over an insecure network.

Where does this idea come from? I see it repeated a lot, but it's not correct.

rsh was common on internal networks, but almost never used on the wider Internet. telnet was everywhere all across the net.

ssh was a revelation and it replaced telnet and authenticated/non-anonymous ftp primarily.

And also sometimes rsh, but less importantly.

How could it be incorrect? rsh was clearly modelled after rlogin, and ssh was clearly modelled after rsh.

The command line options were almost identical for an easy switch. ssh even respected the .rhosts file! Last time I checked, that functionality was still in place.

Both the rlogin-family of commands and the telnet/ftp-family were in use across the Internet, certainly in cases where Kerberos was used. I would think telnet was more common, certainly so outside the UNIX sphere of influence, but things like Kermit also existed.

They all got SSL-encapsulated versions in time, but Kerberos solved authentication for free, and for the simpler use cases ssh had already taken over by then. And in the longer run, simple almost always wins!

Agree that ssh was modeled after rsh. But rsh was a different kind of security problem, which wasn't really relevant on the wider Internet.

ssh solved the "pass credentials in cleartext over untrusted networks" problem. Consequently it replaced telnet and ftp. It also duplicated the functionality of rsh and rcp, so those protocols became irrelevant. But that was not the important goal.

> Kerberos solved authentication for free,

This made me laugh. Kerberos didn't do anything for free. :)

Even in Athena, Kerberos had reliability problems. In the wider world, it was very hard to find a well-managed Kerberos implementation. Things are different now!

Reply on news.ycombinator.com