openssh unix dev - Apr 2003 - ssh -vvv

Hello All,

I just had an interesting experience tracking down a bug on Solaris 8, and ssh
-vvv was of no help which is part of the reason why I write this email.

When DSA public/private keys fail to authenticate me without a password, it just
falls thru to the next authentication type and I can't see a way to see why
it happened.

The extra debug levels don't tell me "Hey you idiot, the permissions
are wrong on the home directory", or "sorry dummy, but the PAM library
(or whatever API it relies on) said I can't authenticate you and I don't
know why

Is there a way to try and get this kind of information?

Usually I can track down problems, but in this case, we had a userid that we
intentionally set to no passwd "*LK*" in Solaris. We had keys setup so
that ssh could be used to run rsync with no pass phrase and after adding a patch
cluster to Solaris it broke.

It turned out that setting a password fixes the problem, but it would have been
nice if debug output told me that.

Is there a debug option to sshd that might have found this?

Thanks in advance for any tips on debugging future ssh authentication problems,

--Buddy

"Lumpkin, Buddy" wrote:
> I just had an interesting experience tracking down a bug on Solaris
> 8, and ssh -vvv was of no help 
[snip]

The server doesn't tell the client why an authentication failed because
that information would be very useful to an attacker.  In general, you
want to "leak" as little information as possible before the user is
authenticated.  This makes the attacker's job harder, and legitimate
admins have other ways of getting the info (server-side debugging, see
below).
> Is there a debug option to sshd that might have found this?
Yes, you want the *server* side debug options.  You can run sshd on
another port to get them without disrupting your production daemon:

/path/to/sshd -ddd -p 2022

then on the client:

ssh -vvv -p 2022 yourhost

This is very helpful for debugging authentication issues, although it's
not always possible; some firewall configs only allow port 22.  In those
cases and if all else fails you can kill off the production daemon and
run the debugging daemon on port 22 (pick a quiet time and keep a few
spare sessions or have alternate access to the box.)

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

Try changing *LK* to something else, e.g. NP.  I recall that Sun change
pam_unix behavior in a patch to treat *LK* specially so that it would
prevent public key authentication.

Lumpkin, Buddy wrote:
> Hello All,
> 
> I just had an interesting experience tracking down a bug on Solaris 8, and
ssh -vvv was of no help which is part of the reason why I write this email.
> 
> When DSA public/private keys fail to authenticate me without a password, it
just falls thru to the next authentication type and I can't see a way to see
why it happened.
> 
> The extra debug levels don't tell me "Hey you idiot, the
permissions are wrong on the home directory", or "sorry dummy, but the
PAM library (or whatever API it relies on) said I can't authenticate you and
I don't know why
> 
> Is there a way to try and get this kind of information?
> 
> Usually I can track down problems, but in this case, we had a userid that
we intentionally set to no passwd "*LK*" in Solaris. We had keys setup
so that ssh could be used to run rsync with no pass phrase and after adding a
patch cluster to Solaris it broke.
> 
> It turned out that setting a password fixes the problem, but it would have
been nice if debug output told me that.
> 
> Is there a debug option to sshd that might have found this?
> 
> Thanks in advance for any tips on debugging future ssh authentication
problems,
> 
> --Buddy
> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
> 
-- 
Michael Haverkamp

ok, I will thanks.

--Buddy

-----Original Message-----
From: Michael Haverkamp [mailto:mhaverka at kcp.com]
Sent: Monday, April 14, 2003 6:00 AM
To: Lumpkin, Buddy
Cc: openssh-unix-dev at mindrot.org
Subject: Re: ssh -vvv


Try changing *LK* to something else, e.g. NP.  I recall that Sun change
pam_unix behavior in a patch to treat *LK* specially so that it would
prevent public key authentication.

Lumpkin, Buddy wrote:
> Hello All,
> 
> I just had an interesting experience tracking down a bug on Solaris 8, and
ssh -vvv was of no help which is part of the reason why I write this email.
> 
> When DSA public/private keys fail to authenticate me without a password, it
just falls thru to the next authentication type and I can't see a way to see
why it happened.
> 
> The extra debug levels don't tell me "Hey you idiot, the
permissions are wrong on the home directory", or "sorry dummy, but the
PAM library (or whatever API it relies on) said I can't authenticate you and
I don't know why
> 
> Is there a way to try and get this kind of information?
> 
> Usually I can track down problems, but in this case, we had a userid that
we intentionally set to no passwd "*LK*" in Solaris. We had keys setup
so that ssh could be used to run rsync with no pass phrase and after adding a
patch cluster to Solaris it broke.
> 
> It turned out that setting a password fixes the problem, but it would have
been nice if debug output told me that.
> 
> Is there a debug option to sshd that might have found this?
> 
> Thanks in advance for any tips on debugging future ssh authentication
problems,
> 
> --Buddy
> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
> 
-- 
Michael Haverkamp