PAM_ERROR_MSG and PAM_TEXT_INFO from modules

[Darren Tucker]

Ethan Benson wrote:
 > eb at socrates ~$ ssh plato
 > Read from remote host plato: Connection reset by peer
 > Connection to plato closed.

I think that "reset by peer" is a problem with the static cleanup 
functions added after 3.7.1p2 but I'm not sure exactly where.

>>As a general policy, sshd will not tell a client *why* an authentication 
>>failed, in order to deny information to an attacker.  Vanilla 
>>/etc/nologin is handled by sshd as a special case.
> 
> 
> right, but really such policy issues like this should be left to the
> discretion of the pam modules, if they choose to give an error message
> via PAM_ERROR_MSG sshd should not override it by throwing that message
> away. (one might consider that a security bug in that pam module, but
> its just that, an issue with the pam module, NOT with sshd).
> 
> most modules don't give any info out by way of PAM_ERROR_MSG, thus
> sshd won't be giving away any info in the normal case.  in cases where
> a module has a good reason to give a custom error, sshd should
> accomidate.  nologin is a good example of this case, but sshd's
> builtin nologin handling doesn't work for me, so i need a custom
> version, my only options for this are 1) modify sshd (which means
> maintaining my own little private fork) 2) using a pam module.

It would be possible to return those via SSH2 keyboard-interactive but 
probably not SSH1 PAM-over-TIS(?).  What do others think of sending the 
PAM error and info messages back to the client for keyboard-interactive?

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