3 ms·

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 imp

by l0wk3y 9y ago

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.

reacweb 9y ago
If you want network performances in script, you can use netcat. r-cmds have reliability issues that are very annoying to diagnose.
johnbellone 9y ago
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.
SwellJoe 9y ago
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.
gbrown_ 9y ago
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.
e12e 9y ago
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.
- khm 9y ago
  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.
yjftsjthsd-h 9y ago
In the unlikely event that it matters, scp and I believe ssh have a flag to use no encryption.
- SwellJoe 9y ago
  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?
  - simias 9y ago
    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 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 https://www.mkssoftware.com/docs/man4/rhosts.4.asp
  - yjftsjthsd-h 9y ago
    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.
moonbug 9y ago
sorry, dude, but even by the frankly glacial standards of progress in the HPC world, you are a decade out of date.

by l0wk3y 9y ago

reacweb 9y ago

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

johnbellone 9y ago

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.

SwellJoe 9y ago

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.

gbrown_ 9y ago

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.

e12e 9y ago

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.

khm 9y ago
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.

yjftsjthsd-h 9y ago

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

SwellJoe 9y ago
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?
- simias 9y ago
  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 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 https://www.mkssoftware.com/docs/man4/rhosts.4.asp
- yjftsjthsd-h 9y ago
  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.

moonbug 9y ago

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