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?
> 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 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.
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.
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.
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
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.
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?
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...
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.
>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).
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.
My colo has a crash cart with keyboard/video/mouse. I don't know what I'd get out of using the serial port for anything. I think only one of my servers actually has an RS232 port, but I haven't actually looked at the hardware in over a year.
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?
Well, in the past we'd use multi-port serial terminal servers and all the hosts had their serial ports as their console hardwired to the terminal server. These days the servers all include IPMI with KVM redirection. But the serial ports are still there.
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.
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.
What does it mean to expose a telnet server on an RS232 interface? Are you running SLIRP on top of it? I think you mean exposing a login prompt (through getty or similar). No telnet server is needed.
That's also a good question. I always used something like minicom or similar to connect when I had to do that sort of nonsense on a regular basis. I don't know how one would use telnet or rlogin to talk to a, say, Cisco, router over RS232. You'd have to jump through some serious hoops, I would think, to use rlogin or telnet.
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.
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?
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).
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.
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.
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.
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, ...
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.
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.
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):
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.
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).
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.
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.
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.
They remove things like rlogin/rsh/telnetd and give you OpenSSH, or BSD window(1) and give you tmux. Or LibreSSL instead of OpenSSL (not an OpenBSD subproject).
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.
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.
I took issue with the previous comment as the wording "get away with" implies the user base has the release and deprecation cycles forced upon them. Whereas it is quite welcomed by the user community. OpenBSD has never targeted those wanting long term support style releases.
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.
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.
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.
> 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.
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.
zfs send is also a general purpose file sync tool, it just has the limitation that server side and client side must use ZFS.
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.
"r" stands for "remote". They predated ssh and were how things were done remotely in the (distant) past. You can pretty much just replace the "r" with an "s" and that's what they did, only without the "secure" provided by ssh/scp/etc.
25 years ago I was using an Amiga 3000 with a 25 MHz 68030 CPU and 8 MB of RAM. It feels pretty distant to me. A lot has changed in that time.
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.
Despite using FreeBSD I had the same question as I had never really touched them. From reading up on it, it looks like they're old remote versions of various commands for interacting with a server/mainframe from a thin client. For example, rcp copies to a remote host, rlogin starts a terminal session on a remote host, etc.
I could well be missing nuance though. My experience with FreeBSD is using it for my server for ZFS' gloriousness.
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.
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.
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.
Basically unencrypted straight remote connections, the predecessor of telnet, scp, etc. I always wondered back when FreeBSD was main daily why it was still there.
Well they may not have technically predated then but what I meant is that as far as I know for a while r(etc) was used and then was generally replaced in actual usage by telnet, etc.
It was the other way around. Rsh and rlogin appeared well after telnet, and displaced some telnet use because they were able to do password-free connections via .rhosts
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.
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.
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.
Remember it is not about Netflix, Sony and Nintendo getting something for free, it is about ANYONE being able to get it for free, no matter who they are and what they want to do with it. Also, don't forget that some of these companies, like Netflix, for example, do contribute to the project, both in money and in code. But again, this is not the point - next time you'll be lucky and create Netflix 2.0, you'll be able to use FreeBSD code to your business advantage too!
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.
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.
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?
I'd assume rexec runs a command on a remote host non interactively; rsh runs an interactive shell on a remote host; and rlogin allows you to interact with login(1), again on a remote host. But I've not read the man pages as I'm on my phone.
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.
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.
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
Right. They say that rsh can be used to get a login or run a command on a remote host. So why do the other two commands exist? In what situations would a person have wanted to use rlogin or rexec instead of rsh?
Maybe rexec appeared first? And when rsh arrived later, they still kept rexec around? Perhaps they had a lot of shell scripts that contained "rexec" and didn't want to bother changing them to "rsh"? The actual reason is probably so mundane that maybe there is no accurate historical information on this topic.
rlogin's aim is to open an interactive session with a remote host. rsh can do that also but is mainly used to run a command remotely. Access control is generally configured on the remote host using a file named .rhosts. If there is no authorisation in .rhosts, rlogin will ask for the password.
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.
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.)
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..."
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.
These commands have deprecated themselves because of many limitations that were hitting almost randomly (for example https://stackoverflow.com/questions/12677712/rsh-running-out...). We had to migrate all the scripts using r-cmds to ssh because of reliability issues when the number of hosts was increasing.
"r-commands" is to rsync as OpenSSL is to OpenSSH. That is, they share the same prefix, have somewhat overlapping usage cases, but are actually completely unrelated to each other.
My immediate reaction was based upon actually reading the headlined message, which lists all 8 commands explicitly. Of course, it has been long known, pretty much since the birth of SSH in fact, that these commands are not the general purpose tools that they were originally designed to be and that their general purpose use is problematic. So my immediate reaction was also based upon knowing exactly what the problem being addressed was, in fairness.
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". (-:
I am going to miss ruptime as a troubleshooting tool. Sure I can check a web based monitoring tool; its only 100 times slower than typing "ruptime" at any CLI I'm logged into. Most of modern progress revolves around making things slower and less productive, in general. zabbix-cli seems focused on CLI based provisioning of Zabbix. Maybe with a couple minutes effort I could make a very short perl script that massages the output of a wget against a zabbix monitoring server URL to output something kind like ruptime. I could name it zuptime. Ahhh progress.
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.
They did a cost benefit analysis, and it turns out that it's actually cheaper to buy new disk drives than to pay someone by the hour to remove files, so rm was just not worth it any more.
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?