Subject: Re: A couple of security-related issues.
To: Manuel Bouyer <email@example.com>
From: Richard Rauch <firstname.lastname@example.org>
Date: 12/26/2000 16:18:05
[Aside: Since you asked a number of questions, I'm providing the answers
for reference. However, if you skim a ways down, you will see that I have
worked out the solution to the problem with OpenSSH & the otp prompts.)
On Tue, 26 Dec 2000, Manuel Bouyer wrote:
> On Sun, Dec 24, 2000 at 05:25:34PM -0600, Richard Rauch wrote:
> > > > 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?
> Don't know. what does it say when you connect using the -v flag ?
/~~~ ssh -v ... (excerpt)
SSH Version OpenSSH_2.2.0 NetBSD_Secure_Shell-20001003, protocol versions
Compiled with OpenSSL (0x0090581f).
debug: Reading configuration data /etc/ssh.conf
debug: ssh_connect: getuid 0 geteuid 0 anon 0
debug: Connecting to tesla.eecs.ukans.edu [188.8.131.52] port 22.
debug: Allocated local port 1016.
debug: Connection established.
debug: Remote protocol version 1.99, remote software version OpenSSH-2.1
debug: Local version string SSH-1.5-OpenSSH_2.2.0
debug: Waiting for server public key.
debug: Received server public key (768 bits) and host key (1024 bits).
debug: Host 'tesla.eecs.ukans.edu' is known and matches the RSA host key.
debug: Encryption type: 3des
debug: Sent encrypted session key.
debug: Installing crc compensation attack detector.
debug: Received encrypted confirmation.
debug: Doing skey authentication.
\___ ssh -v ... (excerpt)
After that, it gives me the ``otp'' prompts.
> > > I've run into this as well, and discovered it falled back to otp when
> > > 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
> > 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
> > If I use 1.5, proper, with OpenSSH, I first get an OTP challenge. Only
> And with standart passwd it works ? Then it can be an option of the local
> ssh. What does the ssh.conf man page tell about this ?
Yes, standard passwords work well. I'd like to skip right to the standard
passwords, though, rather than getting these OTP requests/prompts. That's
where I started. (^&
$ man ssh.conf
man: no entry for ssh.conf in the manual.
$ man 5 ssh.conf
man: no entry for ssh.conf in the manual.
(Hm, that word ``no'' should probably be capitalized, as long as we have a
period to end the ``sentence''. (^& Of course, then, we need to add a
verb. ``man: No entry was found in the manual for %s.'', perhaps? Or, if
one prefers, ``man: No entry for %s was found in the manual.'')
However, on a second pass through ssh's man-page, I looked for
skey. (Previously, not knowing that it was skey-related, I had looked for
otp/OTP, and expansions thereof. The otp prompt _really_ should mention
something about skey! IMHO.)
Anyway, the /etc/ssh.conf option that one needs
is: SkeyAuthentication. Under OpenSSH, this option exists and defaults to
an annoying ``yes''. It is unexampled in the commented out lines in
/etc/ssh.conf, so you really need to know what to look for in the man-page
to figure it out.
> > > > * 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.
> skey related. But skey is part of the base system.
Hm...I was _sure_ that there was something in the past... Maybe it was a
package that edited an /etc file w/o notice, leaving the impression that
the /etc file had always been that way? (It now looks to me as if the old
ssh package did this.)
Still, we have (if commented-out) /usr/pkg/etc/rc.d/apache referenced from
rc.local. And do you object to /etc/man.conf refering to /usr/pkg
directories? (^& As long as the obvious does-it-exist check is made, it
seems reasonable to use audit-packages in the daily security run. The
leap does not seem so large to me.
> > 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)
> Hey, it's the only account with a passwd out of the box :)
> This assumes someone reads root message on a regular basis. The best way to
> do this is to redirect the messages to one or more regular account :)
I do read them. Regular as a broken clock, even! (^& (Seriously,
sometimes I let a week or more go by, but I generally read root's mail
from time to time, precisely because of things like the daily security
report---which on my system _does_ include audit-packages. And I don't
really want to have it jammed into my regular mailbox. I just don't read
root's mail on a _daily_ basis.)
"I probably don't know what I'm talking about." --email@example.com