> >    I seem to remember reading about One Time Passwords as a feature
> >    of kerberos.  I decided that it sounded a bit over the top to
> 
> No, it's skey. It's also here for telnet and rlogin.

Ah.  And is it OpenSSH or the remote sshd that is giving the
less-than-helpful ``OTP'' prompt?


> >    a reason that I should want OpenSSH to do this?  (Or am I missing
> >    the point of one-time passwords?)
> > 
> >    (OpenSSH only does this with some hosts.  My other computer is still
> >    on 1.5_ALPHA with ssh[d], and doesn't do the ``otp'' stuff to me.)
> > 
> >    I couldn't see any options in ssh's man-page that seemed to govern
> >    this...
> 
> I've run into this as well, and discovered it falled back to otp when
> the login is invalid. I've found several reasons for a login to be invalid:
> unknown login, the shell doesn't exists (it took some time to find this
> one :), ...
> Check that you can properly log on the console.

The console of the remote machine?  I don't have access to that
(physically).  I suppose that I wasn't very clear about the situation
w.r.t. the machines.  I have two NetBSD machines, here (one on 1.5, on e
on 1.5_ALPHA).  They interoperate nicely.  I have access to several remote
machines at KU.  We'll call one of them ``tesla'' (because that happens to
be its name).  I don't know where tesla is, and don't have physical access
to tesla.

If I use my 1.5_ALPHA machine to connec to tesla, all is well.  I get a
password prompt; I answer it; I login.

If I use 1.5, proper, with OpenSSH, I first get an OTP challenge.  Only
after failing it 3 times does it fall back to a standard password.  This
happens on every login.

I cannot login to the tsla console, but I've always been able to ssh into
it (and still can do so).

I do NOT have my tesla account set up to bypass normal login.  (I know
that you can do that with ssh, and I experimented with it when I set up a
small CVS repository.  But for normal access, I prefer to keep my password
shar in my head by using it for normal logins.


> >  * Old /etc/security.conf had check_rhosts=NO, with a comment of
> >    ``Don't turn this on; malicious users can take advantage''.  Now,
> >    it is check_rhosts=YES, with no comment.  I assume that whoever
> >    made the change knew what they were doing; still, can someone
> >    (briefly) explain why it wasn't okay before, but is okay now?
> 
> I seem to remember it was an issue with symlinks and find. I don't know
> the details, you may want to check the commit message for the security
> script :)

(^&  My network feed is a bit cranky today, but maybe I'll give the commit
messages a peek in a day or two.


> >  * I figured that audit-packages would be in /etc/security by now.
> 
> audit-packages is a package, it's not part of the base system.

Yes, but I seem to recall that we had things (like ssh-related, or
skey-related?) in daily/secure/something before.  You just check to see if
the pkg is where it ``should''  be, and if it is, then run it.

If the base system migrates into a packaged form, the line between
packages and base system will also become fuzzy.  Start now and avoid the
rush.  (^&


> >    Did it come too late, or was it just an oversight?  (I run it
> >    in my /etc/security, though I must admit that I don't check the
> >    results as often as I could.  Maybe I should have security's
> >    output go to my main account instead of to root?)
> 
> you should forward all root mail to individual account(s). Postmaster
> and abuse too.

I assumed that there was a good reason to have them all directed to
root, since that's how it comes out of the box.  (sigh)



Thanks for your answers, in any case.  (^&


  "I probably don't know what I'm talking about." --rauch@eecs.ukans.edu