Bug 249332 - 'rsh' no longer works
'rsh' no longer works
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: net-tools (Show other bugs)
7
All Linux
low Severity high
: ---
: ---
Assigned To: Radek Vokal
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-07-23 15:13 EDT by Gerry Reno
Modified: 2007-11-30 17:12 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-07-23 16:24:49 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Gerry Reno 2007-07-23 15:13:15 EDT
Description of problem:
Cannot get 'rsh' working

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. install the following:
xinetd
rsh-server

2. issue the following:
service xinetd start
chkconfig rsh on

3. configure the following:
/etc/hosts.equiv:
+ +

/etc/pam.d/rsh:
#%PAM-1.0
# For root login to succeed here with pam_securetty, "rsh" must be
# listed in /etc/securetty.
auth       required     pam_nologin.so
auth       required     pam_securetty.so
auth       required     pam_env.so
auth       required     pam_rhosts_auth.so promiscuous  <--- added promiscuous
to support "+" wildcard
account    include      system-auth
session    optional     pam_keyinit.so    force revoke
session    include      system-auth

/etc/securetty:
console
vc/1
vc/2
vc/3
vc/4
vc/5
vc/6
vc/7
vc/8
vc/9
vc/10
vc/11
tty1
tty2
tty3
tty4
tty5
tty6
tty7
tty8
tty9
tty10
tty11
rsh

/etc/xinet.d/rsh:
# default: on
# description: The rshd server is the server for the rcmd(3) routine and, \
#       consequently, for the rsh(1) program.  The server provides \
#       remote execution facilities with authentication based on \
#       privileged port numbers from trusted hosts.
service shell
{
        disable = no
        socket_type             = stream
        wait                    = no
        user                    = root
        log_on_success          += USERID
        log_on_failure          += USERID
        server                  = /usr/sbin/in.rshd
}

So with these configs I would expect 'rsh' to work.  But when we try to run any
'rsh' command from any client we always get "permission denied".  

Actual results:

Here is what we see in the log:
[CODE]Jul 23 13:49:57 grp-01-30-50 xinetd[23876]: xinetd Version 2.3.14 started
with libwrap loadavg labeled-networking options compiled in.
Jul 23 13:49:57 grp-01-30-50 xinetd[23876]: Started working: 1 available service
Jul 23 13:50:01 grp-01-30-50 xinetd[23878]: socket bind: Invalid argument (errno
= 22)
Jul 23 13:50:01 grp-01-30-50 xinetd[23876]: START: shell pid=23878
from=::ffff:192.168.1.150
Jul 23 13:50:01 grp-01-30-50 rshd[23878]: rsh denied to root@192.168.1.150 as
root: Permission denied. 
Jul 23 13:50:01 grp-01-30-50 rshd[23878]: rsh command was 'hostname'
Jul 23 13:50:01 grp-01-30-50 xinetd[23876]: EXIT: shell status=1 pid=23878
duration=0(sec)[/CODE]


Expected results:
'rsh' command succeeds.

Additional info:
Comment 1 Gerry Reno 2007-07-23 15:46:30 EDT
Found the problem.  You still must have a .rhosts defined for each user.

Please close.

Comment 2 Gerry Reno 2007-07-23 16:05:08 EDT
Sorry, spoke too soon.  I can only get it to work with pam_permit.so which
permits all logins.  As soon as I remove pam_permit then it stops working again.
 I used both wildcards "+" as well as hostnames/IP user in both hosts.equiv and
.rhosts without success.
Comment 3 Gerry Reno 2007-07-23 16:24:49 EDT
Ok, found the right formula.  Had to readd "account    include      system-auth"
after removing pam_permit.

Reclosing.

Note You need to log in before you can comment on or make changes to this bug.