Hacker News Reader

Comment by l0wk3y | Hacker News Reader

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.

View on HN

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.

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.

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.

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.

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

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