sahayman@iuvax.cs.indiana.edu (Steve Hayman) (03/16/89)
Back in February when I wasn't paying attention, Rob Gabbard asked: > Has anyone gotten the new -rem option to rbak to work ? The SR10.1 > release notes state that it must be to a host with /etc/rmt that you > can rexec to.... > After mounting a wbak-written tape onto both a Sun and Convex I tried > the following: > > rbak -f 1 -rem sun:/dev/rmt8 -index -all > >After all attempts the message "Login failed." is returned along with >a message from rbak telling me it failed to connect to foreign host. >The account I was doing this from was able to rsh, rlogin, etc. without >the -l option so I know that's not the problem. I figure Apollo is using >some canned account name to connect with the rexec. I've been checking this out - I want to use -rem to write to an 8mm drive attached to one of our Suns. Part of the problem is that Apollo has chosen to have "rbak -rem" connect to the "rexecd" daemon on the remote machine, and not the "rshd" daemon. These two daemons use different permissions schemes. The way it works is that when you connect to rshd (which is what "rsh" does), three strings are sent from your process to the remote rshd: remote-username local-username command (in this case "/etc/rmt") and the remote "rshd" reads the usernames and looks things up in the .rhosts or hosts.equiv file to decide whether to allow this connection. This is probably what you're expecting to happen with "rbak -rem", but Apollo has chosen to connect to the "rexecd" daemon instead. ("ftp" is the only thing I know of that connects to that daemon.) The protocol in this case is slightly different - your process sends these three strings to the remote rexecd remote-username remote-password command and rexecd, instead of checking .rhosts, checks the user/password combination. If this doesn't work, you get the "Login incorrect" message that you're seeing. Now, the problem is, where do the remote username and password come from? All you specified on the "wbak" command line was a machine name. "ftp" at least knows to look in a file called ".netrc" in your home directory, for lines like this: machine some-vax login someuser password thepassword and sends those lines along (yes, it's disgusting having to keep an unencrypted password in a file). I did some checking (by putting some debug statements into the version of "rexecd" on a Sun to which I was trying to dump from an Apollo) and it looks like rbak doesn't consult the .netrc file - it always sends two null strings to the remote "rexecd", followed by the expected "/etc/rmt" commandline. And of course there is no remote account named "" so the connection fails with "Login incorrect". I wish I had source to "rbak" to check this out. There has to be some way to tell rbak the remote userid/password combination, or the rexec protocol is never going to work. I'm in the middle of trying to track this down with Apollo, and will let people know the outcome. Incidentally, Apollo, if you're listening - but I'm going to tell you this on the phone anyway - can you please fix rbak/wbak to use the "rshd" interface instead of "rexecd" ? I hate the idea of keeping passwords in files; you wouldn't have to if rbak/wbak used "rshd" since authentication would be based on .rhosts files rather than passwords. ..Steve -- Steve Hayman Workstation Manager Computer Science Department Indiana U. sahayman@iuvax.cs.indiana.edu