Re: Failed Password Error

From: Mark Olbert (mark_at_arcabama.com)
Date: 12/21/03 

Date: Sat, 20 Dec 2003 19:13:26 -0800

Okay, I know this is a brain-dead way of isolating a problem, but I've downloaded, built and
installed versions of openssh between the last one I had which worked and 3.7.1p2.

What I found is that everything up to and including 3.6.1p1 works fine. The 3.7 versions don't.

Here's a snippet of the DEBUG3 log entry for the 3.6.1p1 successful connection:

Dec 20 19:03:07 pixel sshd[14170]: Connection from 172.196.97.167 port 1062
Dec 20 19:03:07 pixel sshd[14170]: debug1: Client protocol version 2.0; client software version
PenguiNet-$Re$
Dec 20 19:03:07 pixel sshd[14170]: debug1: no match: PenguiNet-$Revision:_1.49.2.3_$
Dec 20 19:03:07 pixel sshd[14170]: debug1: Enabling compatibility mode for protocol 2.0
Dec 20 19:03:07 pixel sshd[14170]: debug1: Local version string SSH-1.99-OpenSSH_3.6.1p1
Dec 20 19:03:07 pixel sshd[14170]: debug2: Network child is on pid 14171
Dec 20 19:03:07 pixel sshd[14170]: debug3: preauth child monitor started
Dec 20 19:03:07 pixel sshd[14170]: debug3: mm_request_receive entering
Dec 20 19:03:08 pixel sshd[14170]: debug3: monitor_read: checking request 4
Dec 20 19:03:08 pixel sshd[14170]: debug3: mm_answer_sign
Dec 20 19:03:08 pixel sshd[14170]: debug3: mm_answer_sign: signature 0x81065c0(143)
Dec 20 19:03:08 pixel sshd[14170]: debug3: mm_request_send entering: type 5
Dec 20 19:03:08 pixel sshd[14170]: debug2: monitor_read: 4 used once, disabling now
Dec 20 19:03:08 pixel sshd[14170]: debug3: mm_request_receive entering
Dec 20 19:03:12 pixel sshd[14170]: debug3: monitor_read: checking request 6
Dec 20 19:03:12 pixel sshd[14170]: debug3: mm_answer_pwnamallow
Dec 20 19:03:12 pixel sshd[14170]: debug3: mm_answer_pwnamallow: sending MONITOR_ANS_PWNAM: 1
Dec 20 19:03:12 pixel sshd[14170]: debug3: mm_request_send entering: type 7
Dec 20 19:03:12 pixel sshd[14170]: debug2: monitor_read: 6 used once, disabling now
Dec 20 19:03:12 pixel sshd[14170]: debug3: mm_request_receive entering
************** here's where the successful connection in 3.6.1p1 diverges ***
Dec 20 19:03:12 pixel sshd[14170]: debug3: monitor_read: checking request 41
Dec 20 19:03:12 pixel sshd[14170]: debug1: Starting up PAM with username "mark"
Dec 20 19:03:12 pixel sshd[14170]: debug3: Trying to reverse map address 172.196.97.167.
Dec 20 19:03:12 pixel sshd[14170]: debug1: PAM setting rhost to "acc461a7.ipt.aol.com"
Dec 20 19:03:12 pixel sshd[14170]: debug2: monitor_read: 41 used once, disabling now
Dec 20 19:03:12 pixel sshd[14170]: debug3: mm_request_receive entering
Dec 20 19:03:12 pixel sshd[14170]: debug3: monitor_read: checking request 3
Dec 20 19:03:12 pixel sshd[14170]: debug3: mm_answer_authserv: service=ssh-connection, style=
Dec 20 19:03:12 pixel sshd[14170]: debug2: monitor_read: 3 used once, disabling now
Dec 20 19:03:12 pixel sshd[14170]: debug3: mm_request_receive entering
Dec 20 19:03:12 pixel sshd[14170]: debug3: monitor_read: checking request 10
Dec 20 19:03:12 pixel sshd[14170]: debug1: PAM Password authentication accepted for user "mark"
Dec 20 19:03:12 pixel sshd[14170]: debug3: mm_answer_authpassword: sending result 1
Dec 20 19:03:12 pixel sshd[14170]: debug3: mm_request_send entering: type 11
Dec 20 19:03:12 pixel sshd[14170]: debug2: pam_acct_mgmt() = 0
Dec 20 19:03:12 pixel sshd[14170]: Accepted password for mark from 172.196.97.167 port 1062 ssh2
Dec 20 19:03:12 pixel sshd[14170]: debug1: monitor_child_preauth: mark has been authenticated by
privileged p$

I tried to do a rough comparison between the two log entries, and what I found is that they match
down through where I put the asterisked comment. At that point, where 3.6.1p1 does a

monitor_read: checking request 41

followed by starting up PAM, 3.7.1p2 does a

monitor_read: checking request 3

followed by a

mm_answer_authserv: service=ssh-connection, style=

I have no idea what, if any, significance this is, but I thought I'd pass it on to you.

- Mark

Relevant Pages

  • Re: Ouch!
    ... to the effect that the only reason it's built like that is 'cos he requested ... it so, and it's not recommended as it's potentially unsafe, and any loss ... You can't ever disclaim responsibility for loss of life, ... it's on record that it was built like that at the specific request of the ...
    (uk.rec.sheds)
  • Re: Ouch!
    ... In message, Austin Shackles writes ... it's on record that it was built like that at the specific request of the ... customer, who was fully informed as to the potential risks involved. ...
    (uk.rec.sheds)
  • Re: [PATCH] gpiolib: Allow user-selection
    ... architecture code didn't request to get it built in. ... I assume this patch was prepared against some ancient out-of-date ...
    (Linux-Kernel)
  • Re: Build is polluted by host build environment.
    ... build is too convoluted to state that the observed breakage ... analysis of what was being built and how it's used. ... Full build log available on request. ... Marcel Moolenaar ...
    (freebsd-current)
  • Re: Incorrect protocol implementation by OpenSSH?
    ... OpenSSH (I just noticed that I wrote OpenSSL in several places instead; ... my apologies for that) server and an OpenSSH client does indeed end up ... the channel request for a shell so that the client sends a request for a ... suggest forcibly closing the channel over which the request arrived. ...
    (comp.security.ssh)