Subject: Re: A couple of security-related issues.
To: Manuel Bouyer <email@example.com>
From: Richard Rauch <firstname.lastname@example.org>
Date: 12/24/2000 17:25:34
> > 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
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
> > 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." --email@example.com