FreeBSD deprecates all r-cmds (rcp, rlogin, etc.)
marc.info
marc.info
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?
The thing that should be deprecated is the server.
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.
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?
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.
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?
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.
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.
Sidenote: ruby was updated from 2.0.0-pSomethingPastOfficialRubyReleases to 2.3.3-p222
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.
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.
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.
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
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.
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
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.
https://www.openbsd.org/plus32.html (OpenBSD 3.2; rlogin/rlogind/rexecd) - 2002.
http://marc.theaimsgroup.com/?l=openbsd-cvs&m=10207238812306... (Edit: 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.
It would actually be pretty interesting to see a timeline of all the things OpenBSD has removed over the years.
- 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.
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.
https://www.openbsd.org/innovations.html
The various plusXX page give you a changelog style, but also the individual release pages are good at highlighting removed and replaced software. Also, the hackathon, t-shirt and release song artwork is great at showing what was going on at the time in the project.
https://www.openbsd.org/lyrics.html
https://www.openbsd.org/hackathons.html
https://www.openbsd.org/tshirts.html
This one is surprisingly relevant: https://www.openbsd.org/images/tshirt-9b.jpg
Neither can I but the man page disappears between 3.7 and 3.8 so you're correct about it being somewhere in 2005.
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.
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.
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.
> 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?
Sorting the options alphabetically is a reasonable choice, but so's sorting (roughly) by category and recency. That way, say, all options relating to links are near each other. Besides, even the venerable pager "more" supports searching, so there's no need to manually page up / down.
And if you're using "less" as your pager, it's easy enough to sort the Options Summary section in the man page.
> Why are all the examples in the middle so I have to page past them to find out what options are available?
Some man pages put the example at the end, which again I agree is reasonable. However, rsync's man page puts it at the top, not the middle, which is also reasonable. When formatted to 80 columns, rsync's man page is ~4200 lines, and the Usage section is at ~line 100, which is nowhere near the middle. Now, you could argue that putting examples 100 lines in is still too far. So what's in the first ~100 lines? A brief -- yes, 100 lines is brief for a tool as powerful as rsync -- description of what rsync is for. Thus, IMO it's already putting examples as near the top as possible.
> Or maybe we have a legit disagreement about what makes a good man page.
Perhaps. rsync's man page is certainly good, but maybe not great. It's very long, but that's unavoidable given it's got so many features. But it could be broken down into multiple man pages instead of one huge monolithic one.
Nevertheless, it's comprehensive, which is more than a lot of other man pages could claim.
The advantage of RSync is that it is independent of the file system - which is at the same time a huge disadvantage of RSync, as it prevents RSync from performing optimizations which zfs send can do.
That's… not general-purpose at all. zfs send is a specific-purpose tool, the specific purpose being to serialise and output a ZFS snapshot.
They were/are not exclusive to FreeBSD.
And, OpenSSH isn't even 20 years old, so it's actually not been that long. SSH was 1995, that's probably the beginning of the ssh epoch and the beginning of the end of the rsh age.
https://en.wikipedia.org/wiki/Rlogin has more background information.
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.
There is no such thing.
I'd be pedantic and rephrase this to - used for networks which you trust.
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.
I could well be missing nuance though. My experience with FreeBSD is using it for my server for ZFS' gloriousness.
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.
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.
rexec is used to launch a remote command using a login and a password. For convenience, these passwords can be stored locally in a file named .netrc.
Rsh was made to run a remote command without a login shell. Like rsh remotehost <command>. If you omit <command> rsh does an execv() of rlogin.
==Rsh vs Rexec==
Rexec allows you to specify a password on the command line, rsh does not...it expects you to either use .rhosts, or enter the password interactively. Rexec also doesn't have the functionality where it invokes rlogin if you omit the command...the command is mandatory.
==Why?==
No idea. Yes, it's odd that it wasn't all made as a single client binary. There were also different daemons on the server side...rexecd, rshd, rlogind. Also fun, there was often another binary called rsh that had nothing to do with this rsh or remote logins. It was a restricted login shell so that you could have limited rights users.
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.
There's a litmus test for determining the people who have read the headlined message, by the way. They will be the people who know that the commands are in ports, because the deprecation notice explicitly states where in ports they are to be found; who know where to find the manual pages, because the deprecation notice is a patch to the manual pages; and who mention "ruptime" and "rwho". (-:
Adding another line to the common role of my ansible commands to pkg install bsdrcmds is annoying but not a terribly high bar.
I kind of like the debian way of splitting out into rwho package and so forth, because I don't want rlogin or rcp.