Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.networking > #1461 > unrolled thread

why does rsh -l ignore .rhosts?

Back to article view | Back to comp.os.linux.networking

Contents

  why does rsh -l ignore .rhosts? "Ralph" <ralphzodapn@ymeal.com> - 2012-06-05 11:41 +0000
    Re: why does rsh -l ignore .rhosts? Chris Davies <chris-usenet@roaima.co.uk> - 2012-06-05 21:57 +0100
      Re: why does rsh -l ignore .rhosts? "Ralph" <ralphzodapn@ymeal.com> - 2012-06-06 19:39 +0000
        Re: why does rsh -l ignore .rhosts? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-06-07 08:03 +0000
        Re: why does rsh -l ignore .rhosts? Chris Davies <chris-usenet@roaima.co.uk> - 2012-06-07 10:21 +0100
    Re: why does rsh -l ignore .rhosts? MJ <me@invalid.org> - 2012-06-17 04:00 +0000

#1461 — why does rsh -l ignore .rhosts?

I know rsh is old not used anymore, and ssh is the way to go, and rsh
has security issues, but i'm just testing it on a small network of 2
computers where i'm the only user and it's not open to the internet.
It's just for familiarity with it.

I see the man page for rshd says as quoted..

My question Why is it that when you do rsh -l (to specify a different
username than the current one) Why does it ignore .rhosts?



http://linux.die.net/man/8/in.rshd
"8. Rshd then validates the user using ruserok(3), which uses the file
/etc/hosts.equiv and the .rhosts file found in the user's home
directory. The -l option prevents ruserok(3) from doing any validation
based on the user's ''.rhosts'' file (unless the user is the superuser
and the -h option is used.) If the -h option is not used, superuser
accounts may not be accessed via this service at all.

The -l option should not be trusted without verifying that it works as
expected with the particular version of libc installed on your system
(and should be tested again after any libc update) because some
versions of libc may not honor the flags used by rshd.

Also note that the design of the .rhosts system is COMPLETELY INSECURE
except on a carefully firewalled private network. Under all other
circumstances, rshd should be disabled entirely."



-- 

[toc] | [next] | [standalone]

#1463

Ralph <ralphzodapn@ymeal.com> wrote:
> I know rsh is old not used anymore, and ssh is the way to go, and rsh
> has security issues, but i'm just testing it on a small network of 2
> computers where i'm the only user and it's not open to the internet.

I'd still go with ssh, and if you want equivalence logins then set up
public/private certificates. (This is all "easy"... just ask if you're
struggling.)


> It's just for familiarity with it.

Mmm, I suppose. But why bother wasting life becoming familiar with
outdated, obsolete, and insecure software for which a better replacement
is available?


> My question Why is it that when you do rsh -l (to specify a different
> username than the current one) Why does it ignore .rhosts?

Fundamentally it's because the trust is applied on the client side, not
on the server, and the rsh application tries hard to pretend to be fair.


> http://linux.die.net/man/8/in.rshd
>   Also note that the design of the .rhosts system is COMPLETELY INSECURE
>   except on a carefully firewalled private network. Under all other
>   circumstances, rshd should be disabled entirely."

I'd go further than that and remove the clause "Under all other
circumstances" entirely.

Really, there are NO circumstances where rsh is better than ssh, and
many where ssh beats rsh hands down.

Chris

[toc] | [prev] | [next] | [standalone]

#1468

Chris Davies wrote:

> Ralph <ralphzodapn@ymeal.com> wrote:
> > I know rsh is old not used anymore, and ssh is the way to go, and
> > rsh has security issues, but i'm just testing it on a small network
> > of 2 computers where i'm the only user and it's not open to the
> > internet.
> 
> I'd still go with ssh, and if you want equivalence logins then set up
> public/private certificates. (This is all "easy"... just ask if you're
> struggling.)
> 
> 
> > It's just for familiarity with it.
> 
> Mmm, I suppose. But why bother wasting life becoming familiar with
> outdated, obsolete, and insecure software for which a better
> replacement is available?
> 

Well, it's less complex, I don't mean less complex to use or less
complex to learn. I mean less complex functionally, and so how it works
behind the scenes, the code, is less complex. And I like the fact that
it's closer to the machine in that sense.

If I wanted to have a look in wireshark, there'd be more that I can
read, less is hidden from me.

I also like to have some familiarity with the spring from which ssh
sprung, the void it filled, the problems it solves.

Also, if I read a chapter of a book, and it talks briefly about the
inetd super server, and rexec rlogin, and rsh and rcp.. How things
-were done-, then the contents means more to me  having used them.


While I wouldn't need encryption on a private LAN, and i'm the only
user on it, I see that rlogin and rsh etc are still functionally a bit
naturally limited in passwordless logins. If you specify a different
user, you must enter a password.

I know ssh enough that I can do passwordless logins with it with keys.
I don't plan to actually use rsh beyond familiarity(which I think i've
got now).. and I particularly don't plan to use it given that
limitation it has -functionally- with passwordless logins, that you
have to be the same user as the one on the remote machine for it to be
passwordless.

<snip>

[toc] | [prev] | [next] | [standalone]

#1469

On Wed, 2012-06-06, Ralph wrote:
> Chris Davies wrote:
>
>> Ralph <ralphzodapn@ymeal.com> wrote:
>> > I know rsh is old not used anymore, and ssh is the way to go, and
>> > rsh has security issues, but i'm just testing it on a small network
>> > of 2 computers where i'm the only user and it's not open to the
>> > internet.
>> 
>> I'd still go with ssh, and if you want equivalence logins then set up
>> public/private certificates. (This is all "easy"... just ask if you're
>> struggling.)
>> 
>> 
>> > It's just for familiarity with it.
>> 
>> Mmm, I suppose. But why bother wasting life becoming familiar with
>> outdated, obsolete, and insecure software for which a better
>> replacement is available?
>> 
>
> Well, it's less complex, I don't mean less complex to use or less
> complex to learn. I mean less complex functionally, and so how it works
> behind the scenes, the code, is less complex. And I like the fact that
> it's closer to the machine in that sense.

But you also need to be aware that rsh and friends are /fundamentally/
broken on the modern internet.  They were nice in an earlier world
where only equipment under one trusted sysadmin's control was on the
network, and no untrusted users had root access.  (Perhaps there were
other limitations too; I don't know rlogin too well.)

> If I wanted to have a look in wireshark, there'd be more that I can
> read, less is hidden from me.
>
> I also like to have some familiarity with the spring from which ssh
> sprung, the void it filled, the problems it solves.

Fair enough.

> Also, if I read a chapter of a book, and it talks briefly about the
> inetd super server, and rexec rlogin, and rsh and rcp.. How things
> -were done-, then the contents means more to me  having used them.

Inetd is still alive and well.  I tend to enable traditional inetd
services like echo, discard and (restricted) finger on my machines.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#1470

Ralph <ralphzodapn@ymeal.com> wrote:
> Well, it [rsh/rlogin] 's less complex, I don't mean less complex to
> use or less complex to learn. I mean less complex functionally, and
> so how it works behind the scenes, the code, is less complex.

> I also like to have some familiarity with the spring from which ssh
> sprung, the void it filled, the problems it solves.

Fair enough. I forget I've been using Unix-type systems since the mid 80s.


> Also, if I read a chapter of a book, and it talks briefly about the
> inetd super server, and rexec rlogin, and rsh and rcp.. How things
> -were done-, then the contents means more to me  having used them.

I still use inetd - it's a great piece of my toolkit. There have
been improvements and tweaks along the way, but it's a really quick
and convenient way to bring up a daemon written in nothing more than
shell script. Here's a trivial that appears to offer an FTP service but
actually doesn't:

    #!/bin/sh
    #
    echo "421-FTP not available here."
    echo "421 See http://www.example.com/no-ftp-here for alternatives"
    exit 0

If you create that as /usr/local/bin/no-ftp and make it executable,
drop the following line into inetd and send it a SIGHUP ("killall -HUP
inetd") you have a new service operational:

    ftp     stream  tcp     nowait  nobody  /usr/local/bin/no-ftp


> While I wouldn't need encryption on a private LAN, and i'm the only
> user on it, I see that rlogin and rsh etc are still functionally a bit
> naturally limited in passwordless logins. If you specify a different
> user, you must enter a password.

Yes. On one's on LAN it's not so much the encryption as the functionality
that wins. And I can use one tool family (ssh) regardless of whether
the target is on my LAN or elsewhere.

Chris

[toc] | [prev] | [next] | [standalone]

#1477

On Tue, 05 Jun 2012 11:41:45 +0000, Ralph wrote in
4fcdf079$0$10739$5b6aafb4@news.zen.co.uk :

...
> My question Why is it that when you do rsh -l (to specify a different
> username than the current one) Why does it ignore .rhosts?
...

Others have given preferred solutions, but to answer your question 
simply, ~/.rhosts must be chmod 600 to be trusted.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.os.linux.networking

csiph-web