why does rsh -l ignore .rhosts?

Discussion in 'Linux Networking' started by Ralph, Jun 5, 2012.

  1. Ralph

    Ralph Guest

    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."



    --
     
    Ralph, Jun 5, 2012
    #1
    1. Advertisements

  2. Ralph

    Chris Davies Guest

    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.)

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

    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.

    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
     
    Chris Davies, Jun 5, 2012
    #2
    1. Advertisements

  3. Ralph

    Ralph Guest

    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>
     
    Ralph, Jun 6, 2012
    #3
  4. Ralph

    Jorgen Grahn Guest

    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.)
    Fair enough.
    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, Jun 7, 2012
    #4
  5. Ralph

    Chris Davies Guest

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

    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

    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
     
    Chris Davies, Jun 7, 2012
    #5
  6. Ralph

    MJ Guest

    ....
    ....

    Others have given preferred solutions, but to answer your question
    simply, ~/.rhosts must be chmod 600 to be trusted.
     
    MJ, Jun 17, 2012
    #6
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.