PAM changing user name
Per Hedeland
I've run into the problem described in
http://mail-index.netbsd.org/netbsd-bugs/2005/06/27/0005.html - i.e.
"sshd doesn't honour PAM modules changing PAM_USER" (this is not on
NetBSD though). The specific case matches the Radius example pretty well
- i.e. the user should be allowed to login with any username that gives
sucessful authentication with a Radius server, and the PAM module will
map them all to a single user that exists in the local passwd file.
I'm running OpenSSH 3.8.1p1 with Darren Tucker's fix to make password
authentication work with PAM backported - no problem upgrading to a more
current version, but I'm wondering if this has been addressed in newer
versions of Portable OpenSSH? I couldn't find anything about it in the
ChangeLog. If not, is it "hard" to fix? If needed, I'll probably have a
go at it, so any advice is welcome.
Somewhat surprisingly, it seems keyboard-interactive doesn't even try
PAM in this case, while password does try it, but then rejects the login
anyway ("illegal user" for the original username in both cases). I would
rather have expected the opposite...
--Per Hedeland
p...@hedeland.org
PS I think the "How-To-Repeat" clause in the above report was
misformulated - of course the PAM module must map to an existing local
user. Or at least that's the only case I'm interested in.
Darren Tucker
> I've run into the problem described in
> http://mail-index.netbsd.org/netbsd-bugs/2005/06/27/0005.html - i.e.
> "sshd doesn't honour PAM modules changing PAM_USER" (this is not on
> NetBSD though). The specific case matches the Radius example pretty well
> - i.e. the user should be allowed to login with any username that gives
> sucessful authentication with a Radius server, and the PAM module will
> map them all to a single user that exists in the local passwd file.
>
> I'm running OpenSSH 3.8.1p1 with Darren Tucker's fix to make password
> authentication work with PAM backported - no problem upgrading to a more
> current version, but I'm wondering if this has been addressed in newer
> versions of Portable OpenSSH? I couldn't find anything about it in the
> ChangeLog. If not, is it "hard" to fix? If needed, I'll probably have a
> go at it, so any advice is welcome.
Having PAM map the username is not supported on any version. I'm not sure
how much effort it would be to change (and I'm not sure how it would
interact with privsep either).
> Somewhat surprisingly, it seems keyboard-interactive doesn't even try
> PAM in this case, while password does try it, but then rejects the login
> anyway ("illegal user" for the original username in both cases). I would
> rather have expected the opposite...
I think that has been fixed in the newer versions.
--
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.
Per Hedeland
<43049b52$0$21073$5a62...@per-qv1-newsreader-01.iinet.net.au> Darren
Tucker <dtu...@gate.dodgy.net.au> writes:
>On 2005-08-17, Per Hedeland <p...@hedeland.org> wrote:
>> I've run into the problem described in
>> http://mail-index.netbsd.org/netbsd-bugs/2005/06/27/0005.html - i.e.
>> "sshd doesn't honour PAM modules changing PAM_USER" (this is not on
>> NetBSD though). The specific case matches the Radius example pretty well
>> - i.e. the user should be allowed to login with any username that gives
>> sucessful authentication with a Radius server, and the PAM module will
>> map them all to a single user that exists in the local passwd file.
>>
>> I'm running OpenSSH 3.8.1p1 with Darren Tucker's fix to make password
>> authentication work with PAM backported - no problem upgrading to a more
>> current version, but I'm wondering if this has been addressed in newer
>> versions of Portable OpenSSH? I couldn't find anything about it in the
>> ChangeLog. If not, is it "hard" to fix? If needed, I'll probably have a
>> go at it, so any advice is welcome.
>
>Having PAM map the username is not supported on any version. I'm not sure
>how much effort it would be to change (and I'm not sure how it would
>interact with privsep either).
Thanks for the quick reply - I tried 4.1p1 and it was essentially the
same. Since I need it working and have limited time, I'll probably do
some more or less ugly "local hack" (excluding privsep if that's "too
hard") for now. At least you didn't say "it can't possibly be done".:-)
>> Somewhat surprisingly, it seems keyboard-interactive doesn't even try
>> PAM in this case, while password does try it, but then rejects the login
>> anyway ("illegal user" for the original username in both cases). I would
>> rather have expected the opposite...
>
>I think that has been fixed in the newer versions.
Yes, they seem to work the same in 4.1p1 - both "try" PAM, but
(intentionally) replace the password to make sure it fails.:-)
--Per Hedeland
p...@hedeland.org
Darren Tucker
> In article
><43049b52$0$21073$5a62...@per-qv1-newsreader-01.iinet.net.au> Darren
> Tucker <dtu...@gate.dodgy.net.au> writes:
>
>>Having PAM map the username is not supported on any version. I'm not sure
>>how much effort it would be to change (and I'm not sure how it would
>>interact with privsep either).
>
> Thanks for the quick reply - I tried 4.1p1 and it was essentially the
> same. Since I need it working and have limited time, I'll probably do
> some more or less ugly "local hack" (excluding privsep if that's "too
> hard") for now. At least you didn't say "it can't possibly be done".:-)
It's certainly possible for the privsep=no case, whether or not it's
possible for privsep=yes will depend on when PAM performs the switch.
(If it's just in the authentication or account stacks then privsep will
probably be workable, otherwise it's probably not possible. Certainly
not without a significant amount of work.)
I'm not convinced it's a good idea in general, though, since it means
bypassing at least some of sshd's account validity checks.
>>> Somewhat surprisingly, it seems keyboard-interactive doesn't even try
>>> PAM in this case, while password does try it, but then rejects the login
>>> anyway ("illegal user" for the original username in both cases). I would
>>> rather have expected the opposite...
>>
>>I think that has been fixed in the newer versions.
>
> Yes, they seem to work the same in 4.1p1 - both "try" PAM, but
> (intentionally) replace the password to make sure it fails.:-)
Yeah, this is one of the problems with PAM: it assumes that the
application will play absolutely no part in the authentication process
other than passing messages for it.
There's no way to tell PAM "do whatever you would normally do for a
failed login since I'm going to deny it anyway", so in order to prevent
leaking information (ie fast deny for a good password, slow deny for a
wrong one) sshd has to do nasty hacks such as deliberately trashing the
password response.
Per Hedeland
<43058e87$0$21073$5a62...@per-qv1-newsreader-01.iinet.net.au> Darren
Tucker <dtu...@gate.dodgy.net.au> writes:
>On 2005-08-18, Per Hedeland <p...@hedeland.org> wrote:
>> In article
>><43049b52$0$21073$5a62...@per-qv1-newsreader-01.iinet.net.au> Darren
>> Tucker <dtu...@gate.dodgy.net.au> writes:
>>
>>>Having PAM map the username is not supported on any version. I'm not sure
>>>how much effort it would be to change (and I'm not sure how it would
>>>interact with privsep either).
>>
>> Thanks for the quick reply - I tried 4.1p1 and it was essentially the
>> same. Since I need it working and have limited time, I'll probably do
>> some more or less ugly "local hack" (excluding privsep if that's "too
>> hard") for now. At least you didn't say "it can't possibly be done".:-)
>
>It's certainly possible for the privsep=no case, whether or not it's
>possible for privsep=yes will depend on when PAM performs the switch.
>(If it's just in the authentication or account stacks then privsep will
>probably be workable, otherwise it's probably not possible. Certainly
>not without a significant amount of work.)
It happens in authentication, in pam_[sm_]authenticate() - later seems
pretty weird to me. Incidentally, the "standard" FreeBSD pam_radius
module has functionality like this - see the description of
template_user in http://www.daemon-systems.org/man/pam_radius.8.html
(though I'm actually doing this on Linux, with a (by now) non-"standard"
module).
>I'm not convinced it's a good idea in general, though, since it means
>bypassing at least some of sshd's account validity checks.
My thinking is that those checks should be done *after* the PAM
authentication (and retrieval of the username from PAM), not before. Or
at least that failing the validity checks pre-PAM-authentication should
not be fatal (provided the checks succeed post-authentication). Or at
least that this should be allowed under the control of a config option.
>> Yes, they seem to work the same in 4.1p1 - both "try" PAM, but
>> (intentionally) replace the password to make sure it fails.:-)
>
>Yeah, this is one of the problems with PAM: it assumes that the
>application will play absolutely no part in the authentication process
>other than passing messages for it.
Well, maybe the problem is that sshd insists on playing that part with
PAM authentication too.:-) I'm no great fan of PAM, but I'm sure the
sshd validity checks could be implemented (ssh-specifically if so
desired) within PAM. But I can see that you would get a lot of boring
questions if things like AllowUsers just stopped working when you used
PAM (unless the corresponding config was also in PAM).
>There's no way to tell PAM "do whatever you would normally do for a
>failed login since I'm going to deny it anyway", so in order to prevent
>leaking information (ie fast deny for a good password, slow deny for a
>wrong one) sshd has to do nasty hacks such as deliberately trashing the
>password response.
Hm, PAM shouldn't decide to delay a rejection on its own I think, but
I'm sure that given the lack of a PAM "standard" some implementations
do. In my particular case, I'm testing against a FreeRadius
implementation that delays access-reject but not access-accept (some
sort of DOS prevention according to the docs) - not much PAM can do
about that...
But obviously this isn't really possible to handle with only post-
authentication validity checks - sshd simply won't know if it should
reject the user until after authentication. So it probably should
require turning on a config option, leaving the admin to deal with the
consequences (or avoid them by making sure that no succesful PAM auth
will be subsequently rejected by sshd).
--Per Hedeland
p...@hedeland.org