6 ms·

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

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?

ktRolster 9y ago
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.
- SwellJoe 9y ago
  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.
  - marcosdumay 9y ago
    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.
    - SwellJoe 9y ago
      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?
      - tsomctl 9y ago
        There's this company called Cisco that makes routers with serial ports.
        SwellJoe 9y ago
        Never heard of'em.
      - biktor_gj 9y ago
        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...
        mmarx 9y ago
        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.
      - yellowapple 9y ago
        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.
  - lloeki 9y ago
    I noticed just yesterday that MacOS High Sierra has no ftp(1) command anymore.
    - tambourine_man 9y ago
      Oh my. Can anyone confirm this? It removes on upgrading or just doesn't include it on clean installs?
      - lloeki 9y ago
        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
        tambourine_man 9y ago
        Thanks. Can't say I'm against the decision, but damn…
loeg 9y ago
> 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.
- JdeBP 9y ago
  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 https://reviews.freebsd.org/D11345
  - loeg 9y ago
    I think you meant to reply to a different comment. None of that is relevant here.
kijiki 9y ago
At least on Debian, rsh is just a symlink for ssh, and rcp is just scp.
- SwellJoe 9y ago
  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?
  - k0ngo 9y ago
    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.
    - SwellJoe 9y ago
      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.
  - hazeii 9y ago
    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).
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.
bsder 9y ago
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.
- reacweb 9y ago
  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, ...
citrin_ru 9y ago
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.

ktRolster 9y ago

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.

SwellJoe 9y ago
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.
- marcosdumay 9y ago
  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.
  - SwellJoe 9y ago
    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?
    - tsomctl 9y ago
      There's this company called Cisco that makes routers with serial ports.
      - SwellJoe 9y ago
        Never heard of'em.
    - biktor_gj 9y ago
      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...
      - mmarx 9y ago
        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.
    - yellowapple 9y ago
      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.
- lloeki 9y ago
  I noticed just yesterday that MacOS High Sierra has no ftp(1) command anymore.
  - tambourine_man 9y ago
    Oh my. Can anyone confirm this? It removes on upgrading or just doesn't include it on clean installs?
    - lloeki 9y ago
      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
      - tambourine_man 9y ago
        Thanks. Can't say I'm against the decision, but damn…

loeg 9y ago

> 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.

JdeBP 9y ago
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 https://reviews.freebsd.org/D11345
- loeg 9y ago
  I think you meant to reply to a different comment. None of that is relevant here.

kijiki 9y ago

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

SwellJoe 9y ago
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?
- k0ngo 9y ago
  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.
  - SwellJoe 9y ago
    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.
- hazeii 9y ago
  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).

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.

bsder 9y ago

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.

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

citrin_ru 9y ago

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.