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." --
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
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>
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
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
.... .... Others have given preferred solutions, but to answer your question simply, ~/.rhosts must be chmod 600 to be trusted.
