PAM_AUTH_ERR messages

[Darren Tucker]

Sean wrote:
> On Sat, April 30, 2005 10:49 am, Darren Tucker said:
>>What version of OpenSSH is this, which authentication method, and which
>>module type is denying the login?  In 4.0p1, results of failing account
>>and session modules are sent to the user (account messages via SSH2
>>banner messages, the session modules via the session itself).
> 
> It's Fedora FC3 openssh-3.9p1-8.0.1.  kbd-int password authentication. 
> And it's a session module.

In that case, 4.0p1 already does what you want.  If the session module 
fails, the messages are accumulated, sent down the session and the 
session closed (this is how /etc/nologin works too).

> Originally it was pam_limits doing the login
> denial, but unfortunately it doesn't send any message giving a reason for
> the failure.  So now we have a custom PAM module :o/    I'm rather shocked
> more people aren't running into this.
[...]
>>* For keyboard-interactive, the kbdint machinery currently doesn't send
>>any messages after the authentication fails (ie it won't send a
>>zero-prompt message with the failure text).
> 
> This may be the crux of the problem and is definitely the behavior we're
> seeing.

If it's a session module that's failing then that's not your problem.

>>* The output could be sent in banner messages (however they're a
>>Protocol 2 only feature).
> 
> Hmmm, protocol 2 isn't a problem, however I don't see anything in
> auth-pam.c  about "banner messages".   Are they somehow separate from
> pam_conv messages?

Banner messages are a ssh2 protocol feature (SSH2_MSG_USERAUTH_BANNER), 
the server can send them to the client at any time after the 
authentication has started and before it's finished.  The client is 
supposed to show them to the user. See [1] section 5.4.

The basic idea is you accumulate the PAM_ERROR_MSG and PAM_TEXT_INFO 
messages from PAM, cram them into a SSH2 banner message and fire them at 
the user.

>>* There's also a potential issue with leaking information: it'll behave
>>significantly differently if the authentication is denied for other
>>reasons (eg DenyUsers).
> 
> Well, the message only comes up after someone enters a correct password,
> so I don't think this is actually a leak.

In the case of a failing auth or session module, that's correct.

For a failing auth module, it's a leak.  The question is: is it a 
worthwhile tradeoff?

[1] http://www.ietf.org/internet-drafts/draft-ietf-secsh-userauth-27.txt

-- 
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.