Linux - ServerThis forum is for the discussion of Linux Software used in a server related context.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
You REALLY REALLY REALLY should NOT be using rsh. It is an extremely insecure transport standard. You should instead use ssh.
Assuming you are going to do it anyway despite the advice then you should look for any /etc/xinetd.d file that has "rlogin" or "rexec" in it as that is likely the one that enables rsh (as one of the "r" commands).
If I found anyone using rsh or rlogin on my network I would immediately lock them out and disable their processes pending investigation. Those were retired as a huge security risk along with telnet and ftp nearly 15 years ago.
As recommended above, use the OpenSSH utilities with proper keys to enable that same functions using ssl encrypted traffic.
There are other options, but OpenSSH was designed to do the functions of the older R* utilities without the security violations and exposures.
btw I am in a situation to take backup to tape drive which is attached in another server for which i would need an rsh connectivity to perform the backup.I would stop the rsh service on every servers as soon as the backup is done.
However i cant see any files named rsh,rlogin or rexec inside the directory /etc/xinetd.d. Wt could be the reason ??
To check for r commands in xinet.d files:
cd /etc/xinetd.d
egrep -i "rsh|rexec|rlogin" *
On my one remaining RHEL4 box I see:
eklogin:# description: The encrypting kerberized rlogin server accepts rlogin sessions \
klogin:# description: The kerberized rlogin server accepts BSD-style rlogin sessions, \
kshell:# description: The kerberized rshell server accepts rshell commands \
You should see something similar.
By the way xinetd isn't a default install as I recall on RHEL4 so you may not have it installed. Run "rpm -q xinetd" to be sure the package itself is installed.
Thanks for your response.
btw I am in a situation to take backup to tape drive which is attached in another server for which i would need an rsh connectivity to perform the backup.I would stop the rsh service on every servers as soon as the backup is done.
However i cant see any files named rsh,rlogin or rexec inside the directory /etc/xinetd.d. Wt could be the reason ??
Spell out your words. And to reiterate what others have said, use SSH. There is NO REASON to use rsh over ssh. SSH is easier to script for, more secure, and more flexible.
For extremely large data transfers r commands are faster because they don't encrypt/decrypt. We used to do a database refresh process at a former employer and it kicked off multiple rsyncs. To speed those up we used the option that let us specify rsh but that was many years ago. We also had automated processes in place that would disable r commands in inetd/xinetd periodically so if we forgot to turn off r commands after the transfer it would occur anyway.
For most purposes you really don't want to use r commands. The above was a rather extreme example. I wouldn't want to do it on a daily/nightly basis for backups.
Installing a new rsh-server rpm sorted all my problems out(seems the old rpm was not the correct one).I have done necessary configuration post installation and restarted xinetd service which made the rsh connectivity alive on my system. I had no way other than setting up rsh, though I understand the security risk of using rsh on servers (thanks for bringing out this info).
Can somebody advice me the impact of restarting "xinetd" service in a production-cluster environment ?? (if this doubt can be continued in the same thread)
You don't even have to stop/start it. Just run "ps -ef |grep xinetd" then run "kill -1 <pid>" on the xinetd process ID. This sends a sighup to it. Both inetd/xinetd are designed to reread their configurations when they receive a sighup.
Also restarting xinetd should have no impact so long as it is done quickly:
service xinetd restart - would do it.
inetd/xinetd are simply daemons that "listen" for connections and are there to prevent having to run multiple other application specific daemons running all the time when they might only be needed once in a while. Once inetd/xinetd gets a request for a specific port it starts the application which handles the connection after that so shutting down inetd/xinetd has no impact on application connections already running.
So in a full restart inetd/xinetd would be sound for an extremely short period of time.
Hi TB0ne,
What else can be done to take backup to tape which is in a different server?? To my knowledge 'dump' will use rsh to connect to remote server for backup. Any way to use ssh for dump command ??
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.