rsh and rlogin

[luis de carlos]

Hi,
I have two servers in lab environment, (no outside access)running RHEL 2.1 on IA64 and want to get "r" commands going from host 1 to host 2: rlogin, rsh and rcp (Security is NO issue here).
I have set up on hosts.equiv , .rhosts etc to no avail I get the "connection refused" message .
host 2 hosts.equiv and .rhosts content ... (chmod 400)
uxcoedb001.coe.int +
uxcoedb001 +
10.49.123.22 +
I have also turned xinetd service rlogin on via chkconfig and rebooted .
Any other clues?
Thank you
Luis

[Gopi Sekar]

just ensure you have r* services running on your system. check it by netstat -at and look for port numbers which is generally used by rcp, rsh etc.

also you need to have xinetd service running to handle r* services.

A firewall may be blocking your connections

run nmap from client to the server to find out list of ports listening and it may give you more insight on service running

Hope this helps,
Gopi

[Alexander Chuzhoy]

if you've installed rsh-server,then
do:
chkconfig rsh on
chkconfig rlogin on
otherwise install rsh-server first
You have the rpm on installation disks

[Stuart Browne]

Also check the configuration of the firewall.

What user are you trying to use your 'r' commands as incidentally? If it's as 'root', you'll also need to add an entry for 'rsh' in '/etc/securetty' (just add it to a line at the bottom).

[luis de carlos]

Hi
Thanks for the replies. I have NO firewall. The machines are direct connected to a private lan.
I try both as root and as user.
I have xinetd running, see below :
xinetd based services:
chargen-udp: off
chargen: off
daytime-udp: off
daytime: off
echo-udp: off
echo: off
services: off
servers: off
time-udp: off
time: off
sgi_fam: on
finger: off
rexec: on
rlogin: on
rsh: on
ntalk: off
talk: off
telnet: on
rsync: off
have not located an entry for rlogin or rsh in the /etc/services .
# cat /etc/services | grep rlogin
klogin 543/tcp # Kerberized `rlogin' (v5)
eklogin 2105/tcp # Kerberos encrypted rlogin
kshell 544/tcp krcmd # Kerberized `rsh' (v5)

I did not install Linux in these boxes, so have no idea what the previous admin did.
I suspect that the rshd and logind daemons should be started??? How?
Thanks
Luis

[Stuart Browne]

Those three entries in your services file are not the rsh/rexec/rlogin values, they are for kerberos-over-rsh/rexec/rlogin values.

The ones you want are ports 512,513, and 514 (exec, login, shell) TCP.

To see if they are running, use the command 'netstat -ntlp'.

Do you have any entries in '/etc/hosts.deny' or '/etc/hosts.allow' ? If you do, you'll need to ensure that you're opening a hole for the service you are using (most probably 'login' and 'shell'), i.e.:

in.rshd:10.49.123.22
in.rlogind:10.49.123.22

Also, the '~user/.rhosts' should only have host names in them, unlike the '/etc/hosts.equiv'.

[luis de carlos]

Hi Stuart,
Thanks for the reply, this is what I get for netstat -nltp
[root@uxcoedb002 etc]# netstat -ntlp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:512 0.0.0.0:* LISTEN 1102/xinetd
tcp 0 0 0.0.0.0:32768 0.0.0.0:* LISTEN 900/rpc.statd
tcp 0 0 127.0.0.1:32769 0.0.0.0:* LISTEN 1102/xinetd
tcp 0 0 0.0.0.0:513 0.0.0.0:* LISTEN 1102/xinetd
tcp 0 0 0.0.0.0:514 0.0.0.0:* LISTEN 1102/xinetd
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 872/portmap
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1068/sshd
tcp 0 0 0.0.0.0:23 0.0.0.0:* LISTEN 1102/xinetd
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 1143/sendmail: acce

?????????
Should a service/daemon be explicitely started?

I did the changes you suggested in .rhosts and hosts.allow .. and still get the same connection refused.
When I rlogin to the local machine (i.e to same server) I get prompted for the user password and get in ???
Thanks again
Luis

[Stuart Browne]

Ok, exec, login and shell are listening:

tcp 0 0 0.0.0.0:512 0.0.0.0:* LISTEN 1102/xinetd
tcp 0 0 0.0.0.0:513 0.0.0.0:* LISTEN 1102/xinetd
tcp 0 0 0.0.0.0:514 0.0.0.0:* LISTEN 1102/xinetd

This is good. As the services are designed to be launched from the SuperServer (inet/xinet), this is normal, and how it should be.

Now, you've said that the remote machine is getting the same error still. In the '~user/.rhosts' file, does it have the IP address or host-name (as listed in the '/etc/hosts' file) of the remote machine?

As for the local machine not being able to rlogin to it's self, it's because you've not listed the machine's own IP in the appropriate '.rhosts' file.

All of this being said, it's still sounding like a firewall issue. What does 'iptables -nvL' report?

Are there any log entries in '/var/log/messages' or '/var/log/secure' for the time when you're trying to log in?

And you've still not answered my question about what user you're attempting to do these commands as and to.

[Gopi Sekar]

it sounds like firewall issue.

as stuart mentioned just check 'iptables -L' on the server it should list three chains (input, output, forward) as ACCEPT. if there are any other entries then they are the one which may be causing the problem.

to stop firewall run 'service iptables stop' and then try again

Hope this helps,
Gopi

[Steven E. Protter]

Diagnostic:

tail /var/log/messages on the machine you intend to rsh to.

rsh.

If there are no log entries, then look at network issues, such as firewall. If there are entries, post them and lets see what we can do to solve this issue.

It is a common practice in networks I advise to block the ports on the R services, whether or not there is Internet access. The simple reason is clear text authentication, which I can't deal with.

You might find the same functionality from openssh.

I don't generally block port 22 on my firewall, so if it is a firewall issue, openssh will do the trick.

SEP

[luis de carlos]

OK, The plot Thickens !!!
First, answer to Stuart question : I am trying to connect as a normal user : oracle who has a valid login in both boxes ...
next when I run the iptables -L command I get :
[root@uxcoedb001 root]# iptables -nvL
/lib/modules/2.4.18-e.41smp/kernel/net/ipv4/netfilter/ip_tables.o: init_module: Device or resource busy
Hint: insmod errors can be caused by incorrect module parameters, including invalid IO or IRQ parameters
/lib/modules/2.4.18-e.41smp/kernel/net/ipv4/netfilter/ip_tables.o: insmod /lib/modules/2.4.18-e.41smp/kernel/net/ipv4/netfilter/ip_tables.o failed
/lib/modules/2.4.18-e.41smp/kernel/net/ipv4/netfilter/ip_tables.o: insmod ip_tables failed
iptables v1.2.5: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.

????????????????????????
Well as mentioned , I am not aware of the firewall being used, I ran the services iptables stop and still no joy.

What is more puzzling is that there are no relevant entries in either /var/log/messages or /var/log/secure (ie recorded when commands entered) even with me running rlogin -d ???

Do I have to explicitely start other service? this is the list from chkconfig
[root@uxcoedb002 etc]# chkconfig --list
keytable 0:off 1:on 2:on 3:on 4:on 5:on 6:off
atd 0:off 1:off 2:off 3:on 4:on 5:on 6:off
syslog 0:off 1:off 2:on 3:on 4:on 5:on 6:off
gpm 0:off 1:off 2:on 3:on 4:on 5:on 6:off
sendmail 0:off 1:off 2:on 3:on 4:on 5:on 6:off
kudzu 0:off 1:off 2:off 3:on 4:on 5:on 6:off
netdump-server 0:off 1:off 2:off 3:off 4:off 5:off 6:off
netfs 0:off 1:off 2:off 3:on 4:on 5:on 6:off
network 0:off 1:off 2:on 3:on 4:on 5:on 6:off
random 0:off 1:off 2:on 3:on 4:on 5:on 6:off
rawdevices 0:off 1:off 2:off 3:on 4:on 5:on 6:off
acpid 0:off 1:off 2:off 3:on 4:on 5:on 6:off
ipchains 0:off 1:off 2:on 3:on 4:on 5:on 6:off
iptables 0:off 1:off 2:on 3:on 4:on 5:on 6:off
crond 0:off 1:off 2:on 3:on 4:on 5:on 6:off
anacron 0:off 1:off 2:on 3:on 4:on 5:on 6:off
lpd 0:off 1:off 2:on 3:on 4:on 5:on 6:off
xfs 0:off 1:off 2:on 3:on 4:on 5:on 6:off
ntpd 0:off 1:off 2:off 3:off 4:off 5:off 6:off
portmap 0:off 1:off 2:off 3:on 4:on 5:on 6:off
xinetd 0:off 1:off 2:off 3:on 4:on 5:on 6:off
autofs 0:off 1:off 2:off 3:on 4:on 5:on 6:off
nfs 0:off 1:off 2:off 3:off 4:off 5:off 6:off
nfslock 0:off 1:off 2:off 3:on 4:on 5:on 6:off
identd 0:off 1:off 2:off 3:off 4:off 5:off 6:off
radvd 0:off 1:off 2:off 3:off 4:off 5:off 6:off
rwhod 0:off 1:off 2:off 3:off 4:off 5:off 6:off
sshd 0:off 1:off 2:on 3:on 4:on 5:on 6:off
rstatd 0:off 1:off 2:off 3:off 4:off 5:off 6:off
rusersd 0:off 1:off 2:off 3:off 4:off 5:off 6:off
rwalld 0:off 1:off 2:off 3:off 4:off 5:off 6:off
yppasswdd 0:off 1:off 2:off 3:off 4:off 5:off 6:off
ypserv 0:off 1:off 2:off 3:off 4:off 5:off 6:off
ypxfrd 0:off 1:off 2:off 3:off 4:off 5:off 6:off
winbind 0:off 1:off 2:off 3:off 4:off 5:off 6:off
smb 0:off 1:off 2:off 3:off 4:off 5:off 6:off
arpwatch 0:off 1:off 2:off 3:off 4:off 5:off 6:off
ipvsadm 0:off 1:off 2:off 3:off 4:off 5:off 6:off
netdump 0:off 1:off 2:off 3:off 4:off 5:off 6:off
snmptrapd 0:off 1:off 2:off 3:off 4:off 5:off 6:off
snmpd 0:off 1:off 2:off 3:off 4:off 5:off 6:off
rhnsd 0:off 1:off 2:off 3:on 4:on 5:on 6:off
isdn 0:off 1:off 2:on 3:on 4:on 5:on 6:off
httpd 0:off 1:off 2:off 3:off 4:off 5:off 6:off
squid 0:off 1:off 2:off 3:off 4:off 5:off 6:off
xinetd based services:
chargen-udp: off
chargen: off
daytime-udp: off
daytime: off
echo-udp: off
echo: off
services: off
servers: off
time-udp: off
time: off
sgi_fam: on
finger: off
rexec: on
rlogin: on
rsh: on
ntalk: off
talk: off
telnet: on
rsync: off

[Stuart Browne]

Ok, as 'iptables' didn't workk, try 'ipchains -nvL'. It's an older method of firewalling.

Now, we know the service is 'started and listening' (those three lines form the 'netstat -ntlp' I pasted back proove that), and no. Once you issue 'chkconfig rsh on', it's started and listening.

Things to verify on server machine (i.e. the one you are trying to 'rlogin' into):

ls -l ~oracle/.rhosts
cat ~oracle/.rhosts
cat /etc/hosts.{allow,deny}

The permissions on the '.rhosts' should be no more than 0600. The content of the '.rhosts' file should hvae the machine-name or IP address of the remote machine, and can be pinged.

The '/etc/hosts.allow' & '/etc/hosts.deny' should have enough in them to allow 'in.rshd' and 'in.rlogind' (or both be empty).

Nothing is required on the client machine.

[luis de carlos]

Hi Stuar,
Thanks for your time!
here is the output :
[root@uxcoedb002 etc]# ls -l ~oracle/.rhosts
-r-------- 1 oracle dba 145 Jun 28 15:58 /home/oracle/.rhosts
[root@uxcoedb002 etc]# cat ~oracle/.rhosts
10.49.123.22 oracle
10.49.123.23 oracle
uxcoedb001 oracle
uxcoedb001.coe.int oracle
10.49.123.22
10.49.123.23
uxcoedb001
uxcoedb001.coe.int
[root@uxcoedb002 etc]# cat /etc/hosts.allow
#
# hosts.allow This file describes the names of the hosts which are
# allowed to use the local INET services, as decided
# by the '/usr/sbin/tcpd' server.
#
in.rshd:10.49.123.22
in.rlogind:10.49.123.22
in.rshd:uxcoedb001
in.rlogind:uxcoedb001
[root@uxcoedb002 etc]# cat /etc/hosts.allow
#
# hosts.allow This file describes the names of the hosts which are
# allowed to use the local INET services, as decided
# by the '/usr/sbin/tcpd' server.
#
in.rshd:10.49.123.22
in.rlogind:10.49.123.22
in.rshd:uxcoedb001
in.rlogind:uxcoedb001
[root@uxcoedb002 etc]# ipchains -nvL
Chain input (policy ACCEPT: 4765 packets, 214133 bytes):
pkts bytes target prot opt tosa tosx ifname mark outsize source destination ports
0 0 ACCEPT tcp -y---- 0xFF 0x00 * 0.0.0.0/0 0.0.0.0/0 * -> 22
5 240 ACCEPT tcp -y---- 0xFF 0x00 * 0.0.0.0/0 0.0.0.0/0 * -> 23
192 10558 ACCEPT all ------ 0xFF 0x00 lo 0.0.0.0/0 0.0.0.0/0 n/a
172 9672 REJECT tcp -y---- 0xFF 0x00 * 0.0.0.0/0 0.0.0.0/0 * -> 0:1023
0 0 REJECT tcp -y---- 0xFF 0x00 * 0.0.0.0/0 0.0.0.0/0 * -> 2049
26386 2446K REJECT udp ------ 0xFF 0x00 * 0.0.0.0/0 0.0.0.0/0 * -> 0:1023
0 0 REJECT udp ------ 0xFF 0x00 * 0.0.0.0/0 0.0.0.0/0 * -> 2049
0 0 REJECT tcp -y---- 0xFF 0x00 * 0.0.0.0/0 0.0.0.0/0 * -> 6000:6009
0 0 REJECT tcp -y---- 0xFF 0x00 * 0.0.0.0/0 0.0.0.0/0 * -> 7100
Chain forward (policy ACCEPT: 0 packets, 0 bytes):
Chain output (policy ACCEPT: 3228 packets, 316082 bytes):

[luis de carlos]

ooops forgot the deny ...
[root@uxcoedb002 etc]# cat /etc/hosts.deny
#
# hosts.deny This file describes the names of the hosts which are
# *not* allowed to use the local INET services, as decided
# by the '/usr/sbin/tcpd' server.
#
# The portmap line is redundant, but it is left to remind you that
# the new secure portmap uses hosts.deny and hosts.allow. In particular
# you should know that NFS uses portmap!

[root@uxcoedb002 etc]#

[Stuart Browne · Accepted solution]

And here's why:

[root@uxcoedb002 etc]# ipchains -nvL
Chain input (policy ACCEPT: 4765 packets, 214133 bytes):
pkts bytes target prot opt tosa tosx ifname mark outsize source destination ports
0 0 ACCEPT tcp -y---- 0xFF 0x00 * 0.0.0.0/0 0.0.0.0/0 * -> 22
5 240 ACCEPT tcp -y---- 0xFF 0x00 * 0.0.0.0/0 0.0.0.0/0 * -> 23
192 10558 ACCEPT all ------ 0xFF 0x00 lo 0.0.0.0/0 0.0.0.0/0 n/a
172 9672 REJECT tcp -y---- 0xFF 0x00 * 0.0.0.0/0 0.0.0.0/0 * -> 0:1023
0 0 REJECT tcp -y---- 0xFF 0x00 * 0.0.0.0/0 0.0.0.0/0 * -> 2049
26386 2446K REJECT udp ------ 0xFF 0x00 * 0.0.0.0/0 0.0.0.0/0 * -> 0:1023
0 0 REJECT udp ------ 0xFF 0x00 * 0.0.0.0/0 0.0.0.0/0 * -> 2049
0 0 REJECT tcp -y---- 0xFF 0x00 * 0.0.0.0/0 0.0.0.0/0 * -> 6000:6009
0 0 REJECT tcp -y---- 0xFF 0x00 * 0.0.0.0/0 0.0.0.0/0 * -> 7100


In particular, this line:

172 9672 REJECT tcp -y---- 0xFF 0x00 * 0.0.0.0/0 0.0.0.0/0 * -> 0:1023

What this is doing is rejecting any packet destened for TCP ports 512-514.

So what you need to do is insert some firewall rules to allow it through, i.e.:

ipchains -I input -j ACCEPT -p tcp -y -d 0/0 512:514

[luis de carlos]

Thank you so much to all, you guys were right, it was a firewall issue that I did not even knew was in place!
and in particular, thanks to Stuart for his time, patience and effort ...
Hope this helps others as well
Spot - on .
Beats me how this policy got in, but now I can work ....
:-)))))
Luis