fsfacca@LERC08.LERC.NASA.GOV (Tony Facca) (08/22/89)
We are having a problem with the "bru" routine across the network. The
following command:
bru -cvR -f remote_host.guest:/dev/tape /
results in the following error message:
Password incorrect.
Unable to invoke remote demon at remote_host
bru: "remote_host.guest:/dev/tape": can't open archive: No permission match
bru: "load volume 1 and enter device [default: remote_host.guest:/dev/tape]
We tracked the error from the "Backup -h remote_host /" command until we
determined that the messages were coming from "bru". The following things
have been done:
- setenv netaddr in the PROM Monitor on both machines to the correct
TCP/IP address
- allowed guest login permission to root on the remote machine
- also allowed root login permission using .rhosts on the remote machine
- checked that tftp and bootp deamons are running on both machines
The first line of the error message (Password incorrect.) seems to be the
source of the problem. The remaining messages are generated no matter what
form of the command we tried. For instance, guest@remote_host and
guest@unknown_host.
If anyone has been doing remote tape backups and has seen these symptoms,
please let me know. I have gone through the same thing on other systems
without any problems. We are running version 3.1D of the OS on a Personal
Iris. Thanks in advance.
--
-----------------------------------------------------------------------------
Tony Facca | phone: 216-433-8318
NASA Lewis Research Center |
Cleveland, Ohio 44135 | email: fsfacca@lerc08.lerc.nasa.gov
-----------------------------------------------------------------------------jmb@patton.sgi.com (Jim Barton) (08/23/89)
There is a known (to this newsgroup as well) bug in 3.1D and earlier versions
of bru which forces the remote login to have no password. Your .rhosts
and /etc/hosts.equiv are ignored. I believe that 3.1G fixes this bug, and
it is fixed for sure in 3.2. This may be your problem.
-- Jim Barton
Silicon Graphics Computer Systems "UNIX: Live Free Or Die!"
jmb@sgi.sgi.com, sgi!jmb@decwrl.dec.com, ...{decwrl,sun}!sgi!jmbrpaul@dasys1.UUCP (Rod Paul) (08/24/89)
Remove the passwd field in the guest account on the remote machine. SGI is aware of the problem (not to say the security risk). I suggest not going this route if you have a modem on the remote machine. Once done, you can run other utilities remotely, such as "gr_osview". I can say though, that "bru" is a great tool, and if the backup shells shipped by SGI using "bru", ain't to your liking, write your own interface to "bru". Good luck.
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (08/25/89)
In article <8908232207.AA26042@dasys1.UUCP>, rpaul@dasys1.UUCP (Rod Paul) writes: > Remove the passwd field in the guest account on the remote machine. > SGI is aware of the problem (not to say the security risk). I suggest > not going this route if you have a modem on the remote machine. A "system password" for lines with modems seems like a good idea. As long as the system password is strong enough, one needn't worry about passwords on other accounts. (The cryptographic strength of two passwords is not significantly better than one.) Not having a system password makes user names like "diag", "setup", and "root" worrisome, if you have any incoming modems. Everyone no doubt recalls that a "system password" can be specified with /etc/d_passwd and /etc/dialups. Vernon Schryver Silicon Graphics vjs@sgi.com
fsfacca@LERC08.LERC.NASA.GOV (Tony Facca) (08/30/89)
Just a follow up.. A couple of weeks ago I mentioned we were having trouble getting bru to access remote machines. Several people suggested that the password be removed from "guest" on the remote machines. This worked, thank you. It was also suggested that the problem may be fixed in release 3.1G. After installing 3.1G, I can report that the problem still exists. It was also reported that it is fixed "for sure" in 3.2 -- that would be nice. -- ----------------------------------------------------------------------------- Tony Facca | phone: 216-433-8318 NASA Lewis Research Center | Cleveland, Ohio 44135 | email: fsfacca@lerc08.lerc.nasa.gov -----------------------------------------------------------------------------