Are You Still Using RSH?

• By Russ Hunter
• Jan 30, 2004

Like this article? We recommend
Modern Cryptography: Theory and Practice

Why Not RSH?

RSH (including rcp and rlogin) has been around for a long time. When RSH first came onto the scene, it was an essential tool for UNIX users. By logging into just one system, a user could run commands on any server where he or she had an account and an .rhosts file. Files could be copied from server to server as easily as from directory to directory. With a well-configured RSH environment, a user could type his password first thing in the morning and never have to type it again as he used rlogin to jump from system to system.

"Tell us more, Grandpa!"

"Well, we had to walk six miles in the freezing rain just to get to a green screen terminal with Internet access. But we only typed our password once! It was a golden age, kids!"

So what went wrong? Well, in those days security wasn't a big issue. RSH is convenient, but it has some serious security shortcomings. Like Telnet and FTP, RSH traffic is passed as clear text. If you connect to a server via rlogin and su to the root account, you're sharing that root password with anyone who happens to be listening in on your traffic.

"But our network is strictly switched, and security is good. No one can penetrate our perimeter!"

That may be good enough to keep out the casual hacker, but what if someone discovers a new router exploit and gains access before a patch is released? If you're not practicing defense in depth, the best you can hope for is a red flag on your company's next security audit. The worst-case scenario is an intruder with a free pass to every UNIX server on your network. If this happened, would you want to tell your CIO that the breach could have been prevented?

Reasons Not To Change

Inertia is a powerful force in the IT realm. "If it ain't broke, don't fix it" is an all-too-common refrain when discussing production systems. Many organizations have been using RSH for years, and aren't comfortable with change. In addition to user complaints that ensue if rsh is taken away, automated processes may rely on rsh. If these processes are poorly documented (and at least some of them usually are), disabling RSH is sure to break production. This is a valid concern, but it shouldn't be an excuse to disregard the risks inherent in rsh. We'll deal with those production issues later on.