
FreeBSD deprecates all r-cmds (rcp, rlogin, etc.) - zdw
http://marc.info/?l=freebsd-commits-all&m=149918307723723&w=2
======
SwellJoe
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?

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

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

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

------
notaplumber
I think OpenBSD completely removed them years ago; forget deprecation.

[https://www.openbsd.org/plus32.html](https://www.openbsd.org/plus32.html)
(OpenBSD 3.2; rlogin/rlogind/rexecd) - 2002.

[http://marc.theaimsgroup.com/?l=openbsd-
cvs&m=10207238812306...](http://marc.theaimsgroup.com/?l=openbsd-
cvs&m=102072388123069&w=2) (Edit: [http://marc.info/?l=openbsd-
cvs&m=102072388123069&w=2](http://marc.info/?l=openbsd-
cvs&m=102072388123069&w=2))

They removed telnetd a bit later, 2005~ish? I can't find commits, but rsh/rshd
have no online man pages since 5.6 - 2014.

~~~
stock_toaster
I really have to hand it to the OpenBSD folks. They really have their release
and deprecation cycles nailed down pretty well. I also enjoy the fact that
they seem (to me at least) to rip some of old and clunky bits out sooner than
others.

It would actually be pretty interesting to see a timeline of all the things
OpenBSD has removed over the years.

~~~
sigjuice
OpenBSD can do this and get away with it since its use and deployment is
minuscule compared to other systems.

~~~
gbrown_
No they can "get away with it" due to:

\- Having a regular and well tested release model.

\- Having a clear policy of supporting only the current and previous release.

\- Being a BSD style OS where the kernel, libc, and base programs are
developed and released as a whole.

\- Not making promises about binary compatibility across releases.

~~~
Karunamon
..which insures a miniscule install base. Zero compatibility guarantees and
constant depreciation is anathema to enterprise at least.

~~~
ams6110
Not really, because as mentioned the entire system is the release. They don't
release kernels on their own and the userland is upgraded in lockstep with the
kernel with each release.

That said, they'd be the first to tell you that if their model doesn't suit
your needs, you're free to use another OS. They build and support what they
want. If you want something else, they'll ask you to get involved and do the
work.

------
gbrown_
Recall these were never meant to live very long in the first place.

    
    
        With the internal restructuring completed and the TCP/IP protocols integrated
        with the prototype IPC facilities, several simple applications were created to
        provide local users access to remote resources. These programs, rcp, rsh,
        rlogin, and rwho were intended to be temporary tools that would eventually be
        replaced by more reasonable facilities (hence the use of the distinguishing "r"
        prefix). This system, called 4.1a, was first distributed in April 1982 for local
        use; it was never intended that it would have wide circulation, though bootleg
        copies of the system proliferated as sites grew impatient waiting for the 4.2
        release.
    

[http://www.oreilly.com/openbook/opensources/book/kirkmck.htm...](http://www.oreilly.com/openbook/opensources/book/kirkmck.html)

------
yeasayer
What about "rsync"? I use this command pretty often.

~~~
SwellJoe
Completely unrelated.

~~~
3131s
Yep, rsync is still a relevant and awesome tool. The man page is one of the
nicest I've seen too, 60+ pages in a small font and nicely structured with
many examples.

~~~
jethro_tell
I can't tell if your joking but Everytime I try to use that man page, I end up
on stack overflow. I mean, why are all the options out of alphabetical order?
You want me to page through all of them? Why are all the examples in the
middle so I have to page past them to find out what options are available? It
is such a mess.

Maybe that was the point and I'm just joke_explainer. Or maybe we have a legit
disagreement about what makes a good man page.

~~~
Symbiote
Type / which is the command for search in less, the usual pager that displays
the man page.

~~~
jethro_tell
What if I don't know what options are there so I have to read or skip the
examples to find the options? Most manage use is skimming the terse options
section to remember what flag matches with an option and to remember which
options I want.

I know how to search, it's the only man page I know that is formated this way
and I find it to be a very poor design choice. As if I know what I wanted I
wouldn't be looking in the man page.

------
robin_reala
For non-FreeBSD people, what do the r commands do?

~~~
r1ch
Think of them as wildly insecure versions of SCP / SSH. Trusted LAN only,
trusted users only, etc.

[https://en.wikipedia.org/wiki/Rlogin](https://en.wikipedia.org/wiki/Rlogin)
has more background information.

~~~
peterwwillis
They're not exactly insecure, they're just used for different things, like
networks that are already secure. You can secure existing networks pretty well
against things like MitM, and then it doesn't matter if you use rsh or ssh.
(part of why so many routers still use telnet is it's supposed to only be
enabled on management interfaces)

Quite a few years ago I helped build the public terminal cluster for HOPE.
That year we used a token ring network for all of the hosts. Nobody anywhere
near the conference had any token ring gear whatsoever. It was impossible to
break into the network, so you had to use existing nodes. And the nodes'
adapters had their promiscuous modes disabled in hardware. That plus a
hardened terminal server and an extremely limited thin client meant nobody
could successfully hack the network. You could have used telnet all day and
been totally secure.

Though in conference environments, the network is not the biggest risk for
targeted attacks. Carefully watching your target enter their password is
simpler and more effective.

~~~
gbrown_
> They're not exactly insecure, they're just used for different things, like
> networks that are already secure.

There is no such thing.

I'd be pedantic and rephrase this to - used for networks which you _trust_.

~~~
peterwwillis
I think the engineers setting up red/black networks for the military might
disagree with you, but even in the enterprise 802.1X can result in a secure
local network.

I would say trust is a result of the operation of the network, as you may need
to do something to establish it. And in this vein you're right, "networks you
already trust" definitely would have been better wording.

~~~
richardwhiuk
No. You can't use rlogin on a 802.1X network or a red/black network. Passwords
are transmitted in plain text, which means any other terminal on the network
can sniff the password.

~~~
peterwwillis
Red networks are intended for classified plaintext, by definition...

~~~
richardwhiuk
Passwords aren't classified plain text, they are authentication details and
should be handled differently.

------
tachion
While you're here, have you donated[0][1] yet? :) You may or may not be aware,
but FreeBSD runs your movies on Netflix, your games on PlayStation 4 and
Nitendo Switch, your files on FreeNAS and ZFS, your friends on WhatsApp and
OpenBSD runs everything else on OpenSSH. ;)

So, you may or may not know that, but you need FreeBSD and OpenBSD and they
also need you! Every cent counts and so does every contributor, that helps the
foundations keep their non-profit status.

[0]
[https://www.freebsdfoundation.org/donate/](https://www.freebsdfoundation.org/donate/)

[1]
[https://www.openbsd.org/donations.html](https://www.openbsd.org/donations.html)

~~~
simias
I do donate to FreeBSD and I encourage others to do so, but paying to give
Netflix, Sony and Nintendo the privilege to use a free OS doesn't sound like a
great incentive. They're not exactly nonprofits.

~~~
freehunter
That was my thought too, not a great argument. I don't pay Oracle because my
Bluray player runs Java, Sony pays Oracle to use Java and I pay Sony for the
Bluray player. I don't even need to know it runs Java, it's included in the
purchase price.

Likewise I shouldn't need to know Netflix uses FreeBSD, or the PS4 uses it, or
Nintendo uses it. My users don't know my software runs on Heroku, they're not
being asked to give money to DHH for Rails or become a Postgres sponsor or
donate to the Linux Foundation just because they use a product that uses that
technology on the back end.

If you make a product that directly profits from the work of a non-profit, you
should consider a donation to keep the project around. But if you just use a
product that's built on an open source project in a non-transparent way and
don't actually use the open-source project yourself but you're still donating
to it, you would be a _very_ generous citizen.

If FreeBSD didn't exist, Nintendo and Sony and Netflix would use something
else. If companies that use FreeBSD want to keep using FreeBSD, _they 're the
ones_ who should be paying for it.

It's a little much to ask that everyone donate to every open-source project
they happen to use in an incredibly incidental way. I'd be spending half my
time hunting down projects and the other half cutting checks to them. I donate
to projects I actually use.

------
raldi
I guess at this point I'm never going to learn the difference between rlogin,
rsh, and rexec. Even googling it and reading the first page of results doesn't
clear things up.

~~~
killerbat00
A comment below explains exactly this:
[https://news.ycombinator.com/item?id=14699219](https://news.ycombinator.com/item?id=14699219)

~~~
raldi
No it doesn't. It explains what the three as a group do; what I'm asking is,
what's the difference between these three? Why did we need three separate
commands? When (in the pre-SSH days) would you use one versus the others?

~~~
the_mitsuhiko
SSH also brings these separate commands and a few more. ssh, slogin, scp,
sshd, and sftp.

~~~
raldi
Okay, but that's not the question I'm asking.

~~~
sigjuice
Each of these FreeBSD commands have man pages which your googling should have
shown.

~~~
raldi
slogin is just a symlink to ssh, and sexec does not exist. So the s-commands'
manpages tell me nothing about the difference between rsh, rlogin, and rexec,
or why all three needed to be created.

~~~
sigjuice
rsh, rlogin and rexec each have their own man pages, which you should be able
to find on freebsd.org if google is being difficult.

~~~
JdeBP
The irony here is that these manual pages are the very things being patched
_in the headlined message_. Their exact locations in the source tree, and some
of their contents, are right there in front of us.

~~~
sigjuice
So read the older man pages? Why is this a problem? You can also easily read
the man pages for a specific version of FreeBSD here
[https://www.freebsd.org/cgi/man.cgi](https://www.freebsd.org/cgi/man.cgi)

------
esbranson
Imagine a world where all IP packets are indistinguishable from any other,
where TCP cannot be exploited to block SSH connections, where even key
exchange/agreement cannot be blocked without blocking all IP packets. In such
a world, blocking Wikipedia would be all but impossible without taking the
totalitarian country to ruin.

But IPsec was sabotaged thoroughly. draft-ietf-ipsec-inline-isakmp was
silenced. Now every protocol must implement a security policy and framework
individually, without exception. SSH, TLS, EAP oh my (that is a lot of EAP
methods.)

Vae victis. Woe to the conquered. RIP IPsec.

------
spilk
very edge case, but you can't network-install an SGI machine without an
rlogind on the other end.

~~~
SwellJoe
You're telling me that these machines need an rlogind to install over a
network?
[http://www.sgi.com/products/servers/](http://www.sgi.com/products/servers/)

~~~
tyingq
Probably not. Those run linux. It was a requirement for Irix remote installs.
[http://techpubs.spinlocksolutions.com/irix/remote-
irix-6.5-i...](http://techpubs.spinlocksolutions.com/irix/remote-
irix-6.5-installation-from-linux.html)

~~~
SwellJoe
So FreeBSD should keep shipping rlogin in the default install to support
people who might be installing an OS for which the last major version was
released in 1998 and the last minor update was in 2005? Man, nerds _really_
like to "Well, actually..."

~~~
tyingq
I don't see that anyone suggested that.

~~~
SwellJoe
It's how I interpreted the comment I initially responded to, but I guess it
could have just been an "I remember old computer things, let me tell you about
it." I have those moments sometimes, too.

------
reacweb
These commands have deprecated themselves because of many limitations that
were hitting almost randomly (for example
[https://stackoverflow.com/questions/12677712/rsh-running-
out...](https://stackoverflow.com/questions/12677712/rsh-running-out-of-
ports)). We had to migrate all the scripts using r-cmds to ssh because of
reliability issues when the number of hosts was increasing.

------
notaplumber
"FreeBSD has deprecated rcp/rlogin/rsh in 2017. We're aiming for 2019 for
telnetd and 2025 for SSHv1. No deletions planned at this time."

------
titanomachy
rsync is not one of the deprecated commands. I guess it's not considered an
"r-command", although "sync" is also a command on its own.

~~~
tptacek
Rsync is implemented in terms either of rsh or ssh. It's not an r-command.
It's unrelated to "sync".

------
dijit
Should have been deprecated long ago in my opinion. I've never seen those
commands used in my professional life.

~~~
inopinatus
I have, and I'm sorry to report they may still be in use in healthcare,
government, financial institutions.

------
stock_toaster
About damn time!

------
johnbellone
It's about fucking time.

------
mp3geek
Make a SVN commit to deprecate these commands, it also seems time to
depreciate svn.

------
hendersoon
My immediate reaction and maybe yours too was "woah, including rsync?" And no,
while rsync does indeed begin with a letter R, it is not being removed.

~~~
__s
rm is also not being deprecated

~~~
lsh
thank goodness - I have no idea how I'd run m remotely.

~~~
TheCoreh
the new, secure replacement, sm

~~~
cperciva
No, we use the BSD version of that... bsdm.

~~~
happycube
The requirement to use SNMP with that always put me off.

