Re: PAM changing user name
From: Darren Tucker (dtucker_at_gate.dodgy.net.au)
Date: 08/19/05
- Previous message: Richard E. Silverman: "Re: Client can't connect to the default port, but can connect to other ports"
- In reply to: Per Hedeland: "Re: PAM changing user name"
- Next in thread: Per Hedeland: "Re: PAM changing user name"
- Reply: Per Hedeland: "Re: PAM changing user name"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: 19 Aug 2005 07:47:20 GMT
On 2005-08-18, Per Hedeland <per@hedeland.org> wrote:
> In article
><43049b52$0$21073$5a62ac22@per-qv1-newsreader-01.iinet.net.au> Darren
> Tucker <dtucker@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.
--
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.
- Previous message: Richard E. Silverman: "Re: Client can't connect to the default port, but can connect to other ports"
- In reply to: Per Hedeland: "Re: PAM changing user name"
- Next in thread: Per Hedeland: "Re: PAM changing user name"
- Reply: Per Hedeland: "Re: PAM changing user name"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
|
