marcelo@sparcwood.Princeton.EDU (Marcelo A. Gallardo) (10/29/90)
Hi netters - Once again I turn to you in my hour of need. I've been
trying to setup UUCP on my Mac IIcx - A/UX at home. I've got the modem
setup on the printer port and everything seems ok. Now for the problem.
It seems that when someone tries to call up the system at home (via
UUCP) they get the following message... "HANDSHAKE FAILED: Remote
Refused After Login". I'm a bit puzzled, since I can call up and start a
session with out any problems. I thought it might be the callers
settings may be wrong, but I can switch my setting (from 8-N-1 to 7-E-2
and so on) and still have no problems logging in and moving about the
system.
Any ideas?
.. Marcelo ..
marcelo@phoenix.princeton.edu
marcelo@sparcwood.princeton.edu
marcelo@pucc.princeton.edu
marcelo@idunno.princeton.edu
Marcelo Gallardo
Test and Evaluation Specialist
Princeton University
Advanced Technologies and Applications
609 - 258 - 5661cbradley@blackbox.lonestar.org (Chris Bradley) (10/31/90)
In article <3654@idunno.Princeton.EDU> marcelo@sparcwood.Princeton.EDU (Marcelo A. Gallardo) writes: >It seems that when someone tries to call up the system at home (via >UUCP) they get the following message... "HANDSHAKE FAILED: Remote >Refused After Login". I'm a bit puzzled, since I can call up and start a >session with out any problems. I thought it might be the callers >settings may be wrong, but I can switch my setting (from 8-N-1 to 7-E-2 >and so on) and still have no problems logging in and moving about the >system. > >Any ideas? > It seems that you're having a problem with the added security of A/UX's UUCP. You might start by taking a look at your Permissions file and see if you have added an LOGNAME entry for the remote system, and that the READ, WRITE, COMMANDS, SENDFILES and REQUEST fields are all correct for that remote host. An excellent reference for managing UUCP is found in "Managing uucp and Usenet" (O'Reilly, T, and Todino, G.; 1990 O'Reilly and Associates). This text is available from most computer bookstores, or you might try to reach the publishers at nuts@ora.com. Disclaimer: I have no affiliation with O'Reilly and Associates other than as a (very) satisfied user of their publications. -- Chris Bradley | "There are three things which the public will Businessland Advanced Systems | always clamour for, sooner or later: namely, Dallas, Texas US | Novelty, novelty, novelty." cbradley@blackbox.lonestar.org | -- Thomas Hood 1799-1845
rmtodd@servalan.uucp (Richard Todd) (10/31/90)
cbradley@blackbox.lonestar.org (Chris Bradley) writes: >>It seems that when someone tries to call up the system at home (via >>UUCP) they get the following message... "HANDSHAKE FAILED: Remote >>Refused After Login". I'm a bit puzzled, since I can call up and start a >>session with out any problems. I thought it might be the callers >>settings may be wrong, but I can switch my setting (from 8-N-1 to 7-E-2 >>and so on) and still have no problems logging in and moving about the >>system. >It seems that you're having a problem with the added security of A/UX's >UUCP. You might start by taking a look at your Permissions file and see >if you have added an LOGNAME entry for the remote system, and that the >READ, WRITE, COMMANDS, SENDFILES and REQUEST fields are all correct for >that remote host. That'd be a really neat trick, since A/UX UUCP doesn't *have* a Permissions file (unless someone snuck HoneyDanBer onto A/UX 2.0.1 in the dead of night :-) I know for a fact all releases of A/UX <=2.0 came with old-style (or "Version 2", as the O'Reilly book calls it) UUCP, *not* HoneyDanBer. That said, I'd definitely suspect some problem with the permissions setup and config file somewhere. Make sure that the L.sys file is readable by UUCP (and no one else) and has the proper system name in it and that the USERFILE looks reasonable (definition of "reasonable" to be found in the book mentioned below :-). If the caller's system is HDB, you might ask him to check all *his* fiddly little Permissions files... >An excellent reference for managing UUCP is found in "Managing uucp and >Usenet" (O'Reilly, T, and Todino, G.; 1990 O'Reilly and Associates). Agreed. Don't even think of administering a UUCP setup without a copy of this book. -- Richard Todd rmtodd@uokmax.ecn.uoknor.edu rmtodd@chinet.chi.il.us rmtodd@servalan.uucp "Cancelling a posted message means posting a cancel message."-Maarten Litmaath
alexis@panix.uucp (Alexis Rosen) (10/31/90)
In article <3654@idunno.Princeton.EDU> marcelo@sparcwood.Princeton.EDU (Marcelo A. Gallardo) writes: >It seems that when someone tries to call up the system at home (via >UUCP) they get the following message... "HANDSHAKE FAILED: Remote >Refused After Login". I'm a bit puzzled, since I can call up and start a >session with out any problems. I can't give a definite answer since I figured out A/UX uucp without the benefit of A/UX manuals (there were none), and I never encountered this message. Still, I'll give it a shot... Since uucp doesn't see much difference between calling and being called, the most likely thing is that uushell is screwy. Not surprising. The original looks like this: env "TZ=`/bin/cat /etc/TIMEZONE`" /usr/lib/uucp/uucico This is because the uucico is very very stupid and won't work without TZ being set properly. This caused us incredible amounts of grief when we were getting started. Try changing it to read env "TZ=EST5EDT" /usr/lib/uucp/uucico instead. (Since you're in New Jersey. Otherwise, use the right zone...) If that doesn't do the trick, there are a few other things you could try. Do you have an appropriate entry for them in USERFILE? If not, try appending "sysname,susname<tab><tab>/usr/spool/uucppublic" after the last line. For this to work right, you need to have an entry for the calling system in your etc/passwd. (UUCP can work without this, but then the USERFILE entry would be a bit different, and this configuration is superior anyway.) Add something like apple:*:1001:5:apple.com UUCP link:/usr/spool/uucppublic:/usr/lib/uucp/uushell and then assign it a password with passwd. Of course, replace "apple" and the login description with the appropriate things. If none of this works, you're on your own... One thing that might be instructive is to have them call you with uucico -r0, which calls in slave mode instead of master. If this works, you'll have some idea what to check next. Also, what does you /usr/spool/uucp/LOGFILE say about it? --- Alexis Rosen Owner/Sysadmin, PANIX Public Access Unix {cmcl2,apple}!panix!alexis
thad@cup.portal.com (Thad P Floryan) (10/31/90)
rmtodd@servalan.uucp (Richard Todd) in <1990Oct31.023133.10127@servalan.uucp> writes: That'd be a really neat trick, since A/UX UUCP doesn't *have* a Permissions file ... That said, I'd definitely suspect some problem with the permissions setup and config file somewhere. Make sure that the L.sys file is readable by UUCP (and no one else) and has the proper system name in it and that the USERFILE looks reasonable ... >An excellent reference for managing UUCP is found in "Managing uucp and >Usenet" (O'Reilly, T, and Todino, G.; 1990 O'Reilly and Associates). Agreed. Don't even think of administering a UUCP setup without a copy of this book. True. I don't want to sound smug, but it really took all of about 2 minutes to setup A/UX UUCP's config files. As a starter (assuming you've all the system entries in L.sys (and/or Systems), your /usr/lib/uucp/USERFILE should look something like: , / uucp, / nuucp, / root, / From that point, you can (using the info in the O'Reilly book) proceed to establish more stringent security if desired. I've uucp'd to/from A/UX using both V2 and HDB uucp without any problems. Hmmm, someone references a 1990 edition of the O'Reilly book. The older edition(s) lack a LOT of setup for HDB (e.g. multiple Systems files and other services, use of CLOCAL, etc.) but that doesn't affect UUCP operation under A/UX. If you're really security conscious, you can also enable dialup password protection (yeah, it works in A/UX 2.0) using a management program that was posted to Usenet a year or so ago. AT&T flatly refuses to document this feature and, at the SVR4 developers' conference, indicated again their refusal to "officially" support the feature even though it's been in /bin/login for a l-o-n-g while (do a "strings" on it to see the hints and clues :-). Surprising (to me), I only had to recompile the program on A/UX and everything worked right off. To give you an idea of what I mean, following is an excerpt from dpasswd's README; the program itself is available (source, natch!) at osu-cis (aka cheops.cis.ohio-state.edu, IP 128.146.8.62) and I've tested it with SVR2, SVR3.* and SVR4. The program is by Lenny Tropiano and was initially on the 3B1/UNIXPC (for those wondering why the tty line numbers are so high (up to 255 supported) and what /dev/ph0 and /dev/ph1 are (built-in phone lines for the built-in modem)): `` For those who are unsure what I'm talking about, here's a brief explanation. /bin/login will look in a file called /etc/dialups for tty devices that are to be declared as "dialups". The format of the file is /dev/tty names terminated by newline. If the login tty is found in /etc/dialups, it will then go to /etc/d_passwd, and look for your "login-default shell" in there. The format of this file is: login_default_shell_path:encrypted_passwd: If your shell is there, it will then prompt you for "Dialup Password:" after you enter your initial password correctly. If you enter the dialup password incorrectly, you will be denied login. What you can do with this, is allow everything but /bin/sh, and /bin/ksh to get in without a secondary passwords. (This will prevent having to give people with uucp logins another password -- you can give them one, if you so desire with login shell /usr/lib/uucp/uucico). Sample files are as follows: /etc/dialups: ------------- /dev/tty000 /dev/ph1 /etc/d_passwd: -------------- /bin/sh:xeH0weIpa941Q: /bin/ksh:UeH0wlIpW0gyQ: Usage: dpasswd [-v] [-d] -p program -t terminal -v turn verbose on -d delete restriction -p program add (or delete) restriction for program (use full pathname) -t terminal add (or delete) restriction for terminal (don't use "/dev/") eg. # dpasswd -t tty001 -p /bin/sh # dpasswd -t /dev/ph1 # dpasswd -p /bin/ksh # dpasswd -v -t tty001 dpasswd: Dialup terminal restriction added for /dev/tty001. # dpasswd -v -t tty001 dpasswd: Terminal /dev/tty001 already found in /etc/dialups. # dpasswd -v -t ph1 -p /bin/ksh New Dialup Password: Retype Dialup Password: dpasswd: Dialup terminal restriction added for /dev/ph1. dpasswd: Dialup program restriction added for /bin/ksh. # dpasswd -v -d -t ph1 -p /bin/ksh dpasswd: Dialup terminal restriction removed for /dev/ph1. dpasswd: Dialup program restriction removed for /bin/ksh. Appropriate diagnostics will be given for all cases (hopefully). '' Thad Floryan [ thad@cup.portal.com (OR) ..!sun!portal!cup.portal.com!thad ]