Comment by SwellJoe | Hacker News Reader

Comment by SwellJoe | Hacker News Reader

I'm surprised they're still in there, at all. You can still get them on Linux, but that's just because of the way Linux distros are built; nobody is working on them as a core part of the OS. If they were in ports and just kinda stuck around due to inertia, that'd make sense. But, it seems like these are in the core FreeBSD installation, which is borderline crazy.

One of the (few) things I like about the BSDs over Linux is that there is a core system that is maintained by a unified team working closely together in the same repos and with the same communication channels and the like, and following the same standards for docs, interfaces, etc. I like that aspect because people with good judgement are in charge of the platform itself and you can just sort of assume the default installation is cohesive, secure, and has reasonable defaults. This is sort of an argument against that theory; there's nothing reasonable about having rsh/rcp/etc. on a modern system. I mean, it's mostly harmless, as long as you know enough to never use them and never allow any software you run to use them, but still...why leave a bomb just laying around?

> nobody is working on them as a core part of the OS. If they were in ports and just kinda stuck around due to inertia, that'd make sense

I mean, that's exactly what happened.

It's like if they were just old unmaintained programs in GNU coreutils. No one maintains them, no one uses them, but they keep getting included until a good argument is made to remove them.

Previous efforts to remove them were probably greeted with "well, someone might still use these tools." And placing them in ports is a little bit of work.

As you say, they were mostly harmless to keep.

As I have said elsewhere on this page, there´s an easy litmus test for who has actually read the headlined message. Those people are not asking the "But but but rsync?" questions; are talking about "ruptime" and "rwho" as well; know exactly where in the source tree the manual pages are, because the headlined message is a patch that gives their pathnames; and are not basing their arguments on the idea that these are not in ports, given what the deprecation notice explicitly says.

* https://reviews.freebsd.org/D11345

I think you meant to reply to a different comment. None of that is relevant here.

It's ok to have the commands in there, because you never know when you're going to have to connect to a legacy system (in a recent scan I found 250k open telnet ports).

The thing that should be deprecated is the server.

I think it's something that should be sort of pushed by folks who are upstream. As long as people can continue to use dangerous protocols without friction, they'll keep doing it.

I think it has value for users to say, "Oh, so I need to go install a package in order to continue using this protocol." Maybe that'll trigger a change on the server-side.

There's no problem with exposing a rlogin or telnet server over an RS232 interface, or a USB port. There is no reason why clients for using those should be hard to install.

I'm not saying they should be hard to install; I'm saying they shouldn't be in the core installation.

Also, it's been ~15 years since I used an RS232 interface (for serial interfaces to servers/routers); it's been almost that long since you could buy a system with an RS232 interface at all (aside from maybe embedded systems that haven't been updated in years). And, I've never used a USB port for a terminal connection; I guess it is possible but is it ever done?

But, really, why have something that's so out of the ordinary in a default installation?

There's this company called Cisco that makes routers with serial ports.

Never heard of'em.

All Cisco, HP ProCurve etc. still use serial (they tend to have serial over USB these days) interface for configuration. You can connect via SSH / telnet, but to configure the management interface you first need to connect to that serial port and give it an IP address...

HP/HPE/Aruba switches have shipped with DHCP enabled in the factory config for at least the last seven years, so you very much don't need a serial console to configure those. The Cisco WLAN controller I came across last week, however, wouldn't do anything until you plugged in a serial cable.

I personally use RS232 quite regularly in order to hook into the console ports on Cisco hardware and some servers. Really handy if, say, SSH is disabled on a router and you need to get in to enable it.

>it's been almost that long since you could buy a system with an RS232 interface at all (aside from maybe embedded systems that haven't been updated in years).

I don't know what kind of computers you are buying, but I've yet to see a retail, server-class, motherboard without a 9-pin serial port in the back.

My colo has a crash cart with keyboard/video/mouse. I don't know what I'd get out of using the serial port for anything. I think only one of my servers actually has an RS232 port, but I haven't actually looked at the hardware in over a year.

But, maybe most servers do still have RS232.

Nonetheless, rlogin/rcp/etc. are not useful tools for a serial console. I don't even know how you'd use them in such a circumstance. Are you using rlogin/rsh/rcp/rwhatever over RS232 to your servers? How? Why?

Well, in the past we'd use multi-port serial terminal servers and all the hosts had their serial ports as their console hardwired to the terminal server. These days the servers all include IPMI with KVM redirection. But the serial ports are still there.

As far as using any TCP/IP based protocols over the serial port, I suppose you could do something silly with SLIP or PPP, but honestly I don't know why. The whole point of the serial port is that it's damned simple and firmware can easily initialize it and use it for IO extremely early in the boot process.

How does telnet/rlogin over RS232 work? Do you use SLIP or PPP or is there some other mechanism?

That's also a good question. I always used something like minicom or similar to connect when I had to do that sort of nonsense on a regular basis. I don't know how one would use telnet or rlogin to talk to a, say, Cisco, router over RS232. You'd have to jump through some serious hoops, I would think, to use rlogin or telnet.

It's been so long since I've worked with that kind of thing I didn't really even think through what an odd comment it is to suggest that serial consoles on routers are a good reason to keep rsh around in a default FreeBSD install. It makes no sense at all. I'm beginning to think nerds just like to argue.

Agreed. Minicom is a reasonable choice. These days I use screen /dev/ttyS0

FreeBSD still ships with the "tip" command for that: https://www.freebsd.org/cgi/man.cgi?tip(1)

What does it mean to expose a telnet server on an RS232 interface? Are you running SLIRP on top of it? I think you mean exposing a login prompt (through getty or similar). No telnet server is needed.

I noticed just yesterday that MacOS High Sierra has no ftp(1) command anymore.

Oh my. Can anyone confirm this? It removes on upgrading or just doesn't include it on clean installs?

That was an upgrade. I think this is the right call though, sending a clear signal, yet `brew install ftp` or something might come soon enough for those that need it.

Sidenote: ruby was updated from 2.0.0-pSomethingPastOfficialRubyReleases to 2.3.3-p222

Thanks. Can't say I'm against the decision, but damn…

At least on Debian, rsh is just a symlink for ssh, and rcp is just scp.

That's an interesting choice; I'm not sure it's a good one. While I don't want anyone using the old r protocols, I also don't really want transparent redirects to other protocols. What if a Debian user was in the habit of using "rcp file somehost" and found themselves working on a non-Debian system where rcp was not linked to a secure command?

I'd expect scp to detect (using argv[0]) that it is called through a symlink and behave as rcp, not scp. This is how busybox is implemented, with many programs in one binary.

If it did I'd be really disappointed in the openssh developers.

But, I can see the logic behind your expectation. Bash behaves in POSIX compatibility mode (mostly) when called with 'sh', vim acts like vi when called with 'vi', etc. But, when security is the feature being completely removed to achieve compatibility, it'd be hard to argue it's a good idea.

Indeed, as a regular rsh user, this caught me out; it seems a poor choice to replace a working command with a non-functional alternative (and obviously ssh doesn't want to add a feature like silently falling back to rsh).

Probably the last reason I had to use rcp from a machine like Linux or FreeBSD was Solaris.

It used to be stupidly annoying to get ssh up and running on Solaris machines. rcp was one of the few ways to get the appropriate bits into place so that you could bootstrap ssh and sshd.

IMHO r-cmds should be considered more armful in OS than goto in code. In cases of last resort needs, I would prefer netcat. There is a bunch of last resort tools that should be part of default installation. For example ping, xeyes, ...

rsh was a popular way to control Cisco routers and switches from shell scripts. At least 10 years ago default IOS supported only telnet/rsh and image with SSH was more expensive. I hope now SSH is default in Cisco IOS, but there are a lot of older Cisco devices around.

The r-cmds still have a place within cluster environments where their use is protected from the outside world and the overhead of encryption could adversely impact performance. Given the high percentage of Linux systems on the Top 500 list that's not going to change anytime soon.

I have run into a few situations where rlogin and rsh are still being used, but none of the reasons were due to performance vs ssh. 9/10 is due to having to run down all of the processes, scripts, etc that call out to these. It is mostly as easy as symlink to the secure counterpart.

High speed, low-latency, interconnection in clusters is not done via rcp or scp. Also, encryption has lower performance impact than some would assume.

Nonetheless, even if there is a cluster environment using these old commands for some perceived performance improvement, they're certainly running a bunch of custom software; it's not gonna be a stock OS install. So, there's not gonna be any harm in having to install an extra package to get the r commands.

Having it there by default to serve some tiny segment isn't really sensible.

I'm not saying eradicate these commands from the face of the earth. I just saying putting them into the default installation of any OS in 2017 is an unnecessary risk.

If you want network performances in script, you can use netcat. r-cmds have reliability issues that are very annoying to diagnose.

So rcp et al are used on some HPC systems but not for performance. I've seen it used for private management networks that talk to micro-controllers. Even in that instance it's an ugliness that needs to die.

History has thought us that we should probably be wary of "secure" networks. That said, there are a few cases where I could see a case being made for rsh etc w/kerberos: containers/vms - networking limited to a single physical host, with trusted clients/vms etc.

A "modern" network with ipv6+802.1x+ipsec - a situation where you trust the ip6-address just as much, or more than, a typical ssh host key (typical ssh is set up with trust-on-first use, not with expiring certificates).

Now, this is all balanced against the fact that you probably will use ssh anyway - and a hole in ssh(d) will likely be catastrophic - so in the balance, you might be better off managing one secure infrastructure.

On the other hand, if you've set up proper ipsec with client certificates, and the possibility to "dial-in" -- that still holds - why monitor and maintain two secure stacks, if you fundamentally need to trust each one?

As for Debian, it seems someone made the (poor IMNHO) choice of setting up "alternatives" for rsh to point to ssh (if rsh-client isn't installed):

  $ update-alternatives --query rsh
  Name: rsh
  Link: /usr/bin/rsh
  Slaves:
   rsh.1.gz /usr/share/man/man1/rsh.1.gz
  Status: auto
  Best: /usr/bin/ssh
  Value: /usr/bin/ssh

  Alternative: /usr/bin/ssh
  Priority: 20
  Slaves:
   rsh.1.gz /usr/share/man/man1/ssh.1.gz

As I understand it, part of Google's new approach is indeed moving to secure network links (with policy on top) - in such an environment, I'm not convinced there's much to be gained by layering TLS, ssh, HTTP2+SSL on top of end-to-end client/host authenticated networking/vpn.

You're missing the point. Supercomputer networks tend to be things like infiniband, where you're (usually) not using TCP and the whole point is to enable things like RDMA (yes, that stands for remote direct memory access). IPoIB is available but you pay a performance penalty; on Cray's interconnect the TCP emulation performance has traditionally been really bad.

Google's approach (to anything) is irrelevant to supercomputing, where users' program execution is managed by schedulers and the supercomputer is treated as one unit, despite being made up of many potentially-autonomous nodes. Just about all of the tech you've namedropped is completely unrelated to the manner in which HPC code networks.

Having said that, nobody uses rsh for performance, because if you really want performance you have to skip TCP altogether. People in HPC who are using rsh are using it because of inertia: the same reason the Top500 is the world's largest repository of csh users.

Sounds like we're in agreement: I say I see a couple of uses for rsh, none of which has to do with supercomputers, and you say that there's no special need for rsh with supercomputers, beyond it being convenient on a trusted network.

In the unlikely event that it matters, scp and I believe ssh have a flag to use no encryption.

Not that I'm aware of (at least not in openssh; maybe the commercial ssh has such a "feature"). Do you happen to know what that flag is?

I'm pretty sure it doesn't have one either, and that's by design. It seems very dangerous to have such an option. The best you can if encryption limits you is to use a faster cypher such as arcfour (RC4).

It actually reminded me of this old OpenSSH poster: http://openbsd.appli.se/images/poster2.jpg

IIRC the "++" on the RSH tombstone is a reference to a config directive that would open RSH access to anybody from anywhere, effectively giving you a very simple and rather inconspicuous way to "trojan" any rsh install. With SSH the best you can do is install a public key in ~/.ssh/authorized_keys, but it's not quite as convenient as simply adding a "++" in a file when nobody's looking.

See for instance https://www.mkssoftware.com/docs/man4/rhosts.4.asp

Strange; it appears that you're right. There are patches for `-c none`, but nothing official. Perhaps I'm misremembering sibling's suggestion of using a faster cipher.

sorry, dude, but even by the frankly glacial standards of progress in the HPC world, you are a decade out of date.

Reply on news.ycombinator.com