Mailing List Archive

http://bugzilla.mindrot.org/show_bug.cgi?id=423





------- Additional Comments From michael_steffens@hp.com 2003-08-29 23:06 -------
I just tried with CVS version as of today on HP-UX 11.00.

No, unfortunately it doesn't even get that far. The issue from [BUG 419] is
still unresolved, meaning that PAM session setup breaks with trusted mode and
privsep:

fatal: PAM: pam_open_session(): General Commercial Security error

This can be observed with PAMAuthenticationViaKbdInt enabled, while
"traditional" password authentication got broken entirely with trusted mode
and privsep. Correct passwords are being rejected:

Failed password for ...

When turning off trusted mode the same passwords get accepted again (and
session setup succeeds).



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=423





------- Additional Comments From michael_steffens@hp.com 2003-08-30 00:46 -------
Created an attachment (id=375)
--> (http://bugzilla.mindrot.org/attachment.cgi?id=375&action=view)
Ported version of Dan's original session setup patch

With the attached version of Dan Wanek's original session setup patch
I could at least get login to work again with trusted mode and pivsep.

(I also had to unwrap the struct initialization of sshpam_conv in auth-pam.c,
as the compiler didn't accept the current construct.)

However, it still looks a bit strange. Password authentication only works with
ChallengeResponseAuthentication(?) enabled. Otherwise correct passwords are
being rejected.

With proto 2 I'm getting the usual password prompt from PAM.

With proto 1 it looks like challenge response (but both prompts
popping up immediately)

Password:
Response:

where authentication succeeds after typing the regular user password
as "Response".



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=423





------- Additional Comments From dtucker@zip.com.au 2003-08-30 08:41 -------
Will that patch (attachment #375) cause other PAM-using platforms to cough up a
hairball?



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=423

michael_steffens@hp.com changed:

What |Removed |Added
----------------------------------------------------------------------------
Attachment #375 is|0 |1
obsolete| |



------- Additional Comments From michael_steffens@hp.com 2003-09-01 16:40 -------
Created an attachment (id=376)
--> (http://bugzilla.mindrot.org/attachment.cgi?id=376&action=view)
Corrected port of Dan's original session setup patch

Sorry, with (attachment #375) I introduced a stupid bug, making the
initialization of sshpam_conv conditional (which didn't show up because
USE_POSIX_THREADS was not defined).

The attached version has this one corrected.

When I last tested Dan's proposed modifications on Solaris and Linux, these
didn't hickup. Would prefer someone more familiar with these platforms to
verify, though.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=423





------- Additional Comments From djm@mindrot.org 2003-09-01 16:51 -------
(From update of attachment 376)
>--- auth-pam.c-orig Tue Aug 26 03:58:16 2003
>+++ auth-pam.c Mon Sep 1 08:04:13 2003
>@@ -199,10 +199,15 @@
> {
> struct pam_ctxt *ctxt = ctxtp;
> Buffer buffer;
>- struct pam_conv sshpam_conv = { sshpam_thread_conv, ctxt };
>+ struct pam_conv sshpam_conv;
> #ifndef USE_POSIX_THREADS
> const char *pam_user;
>+#endif
>+
>+ sshpam_conv.conv = sshpam_thread_conv;
>+ sshpam_conv.appdata_ptr = ctxt;

I don't understand this part of the patch. Why does break the initialisation
from the declaration?

>+#ifndef USE_POSIX_THREADS

I'm not sure which version you are diffing against, but CVS HEAD already has
this test.

> #if defined(USE_PAM)
> if (options.use_pam) {
>- do_pam_session(s->pw->pw_name, NULL);
> do_pam_setcred(1);
> if (is_pam_password_change_required())
> packet_disconnect("Password change required but no "
>@@ -561,7 +560,7 @@
>
> #if defined(USE_PAM)
> if (options.use_pam) {
>- do_pam_session(s->pw->pw_name, s->tty);
>+ do_pam_set_tty(s->tty);
> do_pam_setcred(1);
> }
> #endif
>@@ -1235,6 +1234,7 @@
> */
> if (options.use_pam)
> do_pam_setcred(0);
>+ do_pam_session(pw->pw_name,NULL);

This is missing braces after the "if" statement. I.e

if (options.use_pam) {
do_pam_setcred(0);
do_pam_session(pw->pw_name,NULL);
}

I agree that do_pam_session makes more sense is setusercontext, but if we split
the PAM_TTY setting, then we should remove do_pam_session's second argument
entirely.




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=423





------- Additional Comments From michael_steffens@hp.com 2003-09-01 17:24 -------
> ------- Additional Comments From djm@mindrot.org 2003-09-01 16:51 -------
> (From update of attachment 376)
>
>>--- auth-pam.c-orig Tue Aug 26 03:58:16 2003
>>+++ auth-pam.c Mon Sep 1 08:04:13 2003
>>@@ -199,10 +199,15 @@
>>{
>> struct pam_ctxt *ctxt = ctxtp;
>> Buffer buffer;
>>- struct pam_conv sshpam_conv = { sshpam_thread_conv, ctxt };
>>+ struct pam_conv sshpam_conv;
>>#ifndef USE_POSIX_THREADS
>> const char *pam_user;
>>+#endif
>>+
>>+ sshpam_conv.conv = sshpam_thread_conv;
>>+ sshpam_conv.appdata_ptr = ctxt;
>
>
> I don't understand this part of the patch. Why does break the initialisation
> from the declaration?

To be honest, I don't know. Compiler refused it with

error 1521: Incorrect initialization.

>
>
>>+#ifndef USE_POSIX_THREADS
>
>
> I'm not sure which version you are diffing against, but CVS HEAD already has
> this test.

Yes, but I erranously moved initialization inside the #ifndef
block when wanting to get it past the declaration of pam_user.
Correction was to split the #ifndef, and put the initialization
in between.

>
>
>
>>#if defined(USE_PAM)
>> if (options.use_pam) {
>>- do_pam_session(s->pw->pw_name, NULL);
>> do_pam_setcred(1);
>> if (is_pam_password_change_required())
>> packet_disconnect("Password change required but no "
>>@@ -561,7 +560,7 @@
>>
>>#if defined(USE_PAM)
>> if (options.use_pam) {
>>- do_pam_session(s->pw->pw_name, s->tty);
>>+ do_pam_set_tty(s->tty);
>> do_pam_setcred(1);
>> }
>>#endif
>>@@ -1235,6 +1234,7 @@
>> */
>> if (options.use_pam)
>> do_pam_setcred(0);
>>+ do_pam_session(pw->pw_name,NULL);
>
>
> This is missing braces after the "if" statement. I.e
>
> if (options.use_pam) {
> do_pam_setcred(0);
> do_pam_session(pw->pw_name,NULL);
> }

Yep, another stupid bug of mine :(. Thanks for catching.
(This also didn't show up when testing, because options.use_pam
was true, of course.)

>
> I agree that do_pam_session makes more sense is setusercontext, but if we split
> the PAM_TTY setting, then we should remove do_pam_session's second argument
> entirely.

Also agreed. (I used Dan's original modifications as they were, and
these were presumably meant to modify at little as possible.
But there is only one invokation of do_pam_session left, not using
the second argument.)




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=423

michael_steffens@hp.com changed:

What |Removed |Added
----------------------------------------------------------------------------
Attachment #376 is|0 |1
obsolete| |



------- Additional Comments From michael_steffens@hp.com 2003-09-01 18:31 -------
Created an attachment (id=377)
--> (http://bugzilla.mindrot.org/attachment.cgi?id=377&action=view)
3rd version port of Dan's original session setup patch

Now a version taking djm's correction and suggestion into account.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=423





------- Additional Comments From michael_steffens@hp.com 2003-09-02 01:06 -------
Tried to find where the strange password authentication behaviour mentioned
in comment #22 comes from, and why plain old password authentication fails in
HP-UX trusted mode. Maybe this got me a bit closer to how the new code works. :)

Apparently it's falling back to non-PAM authentication for plain old password
authentication (the one where the client prompts "user@host's password:").

This fails in trusted mode, because DISABLE_SHADOW is defined for all versions
of HP-UX, thus getspnam is not being used to retrieve the real pw hash.
Instead the '*' from /etc/passwd is being used. By enabling shadow this can
be fixed. I have tried it and it worked.

On the other hand, with proto 1, TIS authentication has precedence over
password authentication, and it actually works using sshpam_device. PAM
happens to generate the challenge "Password:", and succeeds when getting
the correct password on the prompt "Response:".

In case password via TIS fails (for example because the user was confused by
the prompts), traditional password authentication, bypassing PAM, is being
tried.

Is this correct and the intended order?





------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=423

djm@mindrot.org changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |FIXED



------- Additional Comments From djm@mindrot.org 2003-09-02 23:19 -------
very similar patch applied, thanks.

Please file a separate bug for the HAVE_SHADOW issue



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=423





------- Additional Comments From michael_steffens@hp.com 2003-09-03 00:39 -------
Hi Damien,

thanks for applying!

However, this modification only solves the problem of getting session set up
at all with privsep in trusted mode, but not yet changing expired passwords.
(The one being prerequisite to perform the other.)

This fix would rather apply to BUG #419, which is marked resolved/duplicate
of BUG #83. However, I'm having no idea whether they are related...

Michael



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=423





------- Additional Comments From Todd.Bowden@atosorigin.com 2003-09-03 00:47 -------
Didnt Patch 162 fix all this? I have OpenSSH 3.5p1 working on a HP-UX 11
trusted system in privelage seperation mode with password aging and it works
like a charm.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=423





------- Additional Comments From michael_steffens@hp.com 2003-09-03 01:03 -------
It did, besides the additional suid ssh-chauthtok-helper did not get accepted.

The more elegant approach should be enabled by new PAM code, but is apparently
not active yet. (unless, beat me, I missed something. It didn't work when
I tried yesterday.)





------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.