Re: rsh working intermittently
- From: ibuprofin@xxxxxxxxxxxxxxxxxxxxxx (Moe Trin)
- Date: Sat, 28 Jan 2006 19:47:11 -0600
On 27 Jan 2006, in the Usenet newsgroup linux.redhat, in article
<1138384945.923072.279320@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>, Tom wrote:
>I am trying to install an application that requires this feature works.
> I do not think that this particular application will even use rsh at
>the end, but for some reason the install script tests rsh and returns
>if it is not working.
Bizarre. I've no idea why anyone would require this for an installation,
as most people stopped using (and then stopped installing) rsh years ago
because of abysmal security. The Berkeley 'r' commands were never designed
with any real security.
>The logs say the following when rsh fails:
>localhost pam_rhosts_auth[8114]: allowed to
>username@xxxxxxxxxxxxxxxxxxxxx as username
>localhost in.rshd[8114]: rsh denied to username@xxxxxxxxxxxxxxxxxxxxx
>as username: Permission denied.
OK, PAM is saying OK, but the rsh daemon which is then started doesn't
like something about the authentication. There can't be very much, as all
rsh depends on is source port numbers, host address, username, and that
the command isn't to long. The 'rshd' man page tells the limited story.
>When rsh is successful I get:
>localhost pam_rhosts_auth[8049]: allowed to
>username@xxxxxxxxxxxxxxxxxxxxx as username
>localhost rsh(pam_unix)[8049]: session opened for user username by
>(uid=0)
Are those the same user? How much of a time difference between the "allowed
to" and the following line in each case?
>Actually I can use rsh from root account without this problem. Why do
>you say it should be blocked?
That's been a security problem since the late 1980s. 'rsh' has none, so
allowing root in that was is virtually the same as allowing root with no
password. You are depending solely on IP addresses. This is mentioned
in the rshd man page. What is not mentioned is that non-unix operating
systems don't enforce the Unix concept of privileged port numbers.
>I am not sure how to use netstat in the manner you suggest. Doing
>netstat -c -tupan |grep 127.0.0.1 does not reveal anything interesting.
> When ever I issue an rsh command I get something like:
>
>tcp 0 0 127.0.0.1:1023 127.0.0.1:514 TIME_WAIT -
>tcp 0 0 127.0.0.1:1021 127.0.0.1:514 TIME_WAIT -
The status is 'TIME_WAIT' which is an closed connection. You normally run
through the sequence 'SYN_SENT,', to 'ESTABLISHED', to 'FIN_WAITx', to
'TIME_WAIT' or 'CLOSE_WAIT'. This is briefly described in the 'netstat'
man page.
>tcp 0 0 127.0.0.1:1022 127.0.0.1:1019 TIME_WAIT -
>tcp 0 0 127.0.0.1:1020 127.0.0.1:1019 TIME_WAIT -
No idea what that might be. While 1019 is in the 'registered ports
range', IANA hasn't assigned that port. That's not critical, because
there is nothing that requires that only the registered service may
use the registered port, As a wild guess, this is the 'stderr' connection
used by rsh. Again, you are in the TIME_WAIT status.
I'd look at the /etc/xinetd.d/rsh file to see if there is anything
particular in logging, and then run 'tcpdump -n -i lo -s 1500' to see
if I could spot anything. This _appears_ to be a rshd authentication
problem, though I have no idea why for identical users, it would work
sometime and not others but then start working again without any change
to files or username.
Old guy
.
- Follow-Ups:
- Re: rsh working intermittently
- From: Tom
- Re: rsh working intermittently
- References:
- rsh working intermittently
- From: tgdrozda
- Re: rsh working intermittently
- From: Moe Trin
- Re: rsh working intermittently
- From: Tom
- rsh working intermittently
- Prev by Date: Re: RHCT Books and Preperation???
- Next by Date: Perl debugger
- Previous by thread: Re: rsh working intermittently
- Next by thread: Re: rsh working intermittently
- Index(es):
Relevant Pages
|
