PAM_ERROR_MSG and PAM_TEXT_INFO from modules

[Ethan Benson]

On Mon, Jan 12, 2004 at 09:56:08PM +1100, Darren Tucker wrote:
> Ethan Benson wrote:
> >first pam_motd does not work anymore.
> 
> It worked on RH8 when I tested it.  I have a Debian test box here, I'll 
> see if I can reproduce it.

i didn't fiddle around with that issue too much since im running out
of time this weekend, but i don't think its anything obvious.

> Can you try it as a session module?  I think the error will be output in 
> that case because by the time the session module runs, you have a tty 
> attached to the session.

i have not tried this with the snapshot version, but it did not work
with 3.4.

just tested with the snapshot version (using a different pam (session)
module i wrote, one which also gives a PAM_ERROR_MSG on failure)

here is the output for pubkey auth:

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

and with pam password auth:

erb at socrates ~$ ssh plato
Password:
Read from remote host plato: Connection reset by peer
Connection to plato closed.
erb at socrates ~$

so unless the login is permitted to happen, PAM_ERROR_MSG and
PAM_TEXT_INFO are both thrown away.

> >so that this would work with both pubkey and password auth I
> >configured the module as a requisite account module, this works, ssh
> >denies access when it should, but it does not print the contents of
> >/etc/noulogin.  that is a problem since to the users it looks like ssh
> >is malfunctioning and they bug me about why, if the noulogin file were
> >printed properly they would get the proper explanation.
> 
> 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.

i chose option 2 since my problem is the precise kind of thing pam was
made to solve.

> 
> ENOFOOTNOTE?

eh? sorry i don't know what you mean here.

> >system is Debian 3.0
> [snip]
> >as an unrelated sidenote i tested password expiration and it seems to
> >work properly, it looks like the pam issues are finally getting worked
> >out, which is good news.
> 
> Excellent news, thanks.

Ill try to do more pam testing on the snapshot releases as i have
time.  and i can test patches to fix the above.

-- 
Ethan Benson
http://www.alaska.net/~erbenson/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 240 bytes
Desc: not available
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20040112/fef39b82/attachment.bin