Re: Now with PAM? Solaris 10 sshd and ticket forwarding
On Mon, Nov 05, 2007 at 04:14:21PM -0500, Jeff Blaine wrote: > Very likely. One heads down roads like these and > the default 'other' stack are the last things to > consider (for me at least). If we shipped a default PAM configuration for every application then modifying the "other" one wouldn't be a way to shoot yourself in the foot. But then you'd have to do that much more editing of pam.conf... Nico -- Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Now with PAM? Solaris 10 sshd and ticket forwarding
Very likely. One heads down roads like these and the default 'other' stack are the last things to consider (for me at least). Nicolas Williams wrote: > On Mon, Nov 05, 2007 at 02:43:56PM -0500, Jeff Blaine wrote: >> Those 3 lines make it work. Thanks again, Doug. >> >> I can't really imagine where I'd be with this unless >> someone had figured out all of this esoterica before >> me. Sheesh. > > The default other stack should have worked just fine. > Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Now with PAM? Solaris 10 sshd and ticket forwarding
On Mon, Nov 05, 2007 at 02:43:56PM -0500, Jeff Blaine wrote: > Those 3 lines make it work. Thanks again, Doug. > > I can't really imagine where I'd be with this unless > someone had figured out all of this esoterica before > me. Sheesh. The default other stack should have worked just fine. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Now with PAM? Solaris 10 sshd and ticket forwarding
Those 3 lines make it work. Thanks again, Doug.
I can't really imagine where I'd be with this unless
someone had figured out all of this esoterica before
me. Sheesh.
Douglas E. Engert wrote:
> The problem may be in the pam.conf. With sshd-gssapi,
> only the PAM session and account routines are called, and
> you don't use the pam_krb5. The sshd stores the credentials
> for you,not PAM.
>
> We use this in /etc/pam.conf, (but all uncommented.)
> Try with just the 3 uncommented lines.
>
>
> sshd-gssapi account requisite pam_roles.so.1
> sshd-gssapi account required pam_unix_account.so.1
> #sshd-gssapi account required /krb5/lib/pam_krb5_ccache.so.1
> ccache=/tmp/krb5cc_%u_%p
>
> sshd-gssapi session required pam_unix_session.so.1
> #sshd-gssapi session required /krb5/lib/pam_afs2.so.1
> #sshd-gssapi session required /krb5/lib/pam_krb5_ccache.so.1 clean
>
> The pam_afs2 is the local equivelent of pam_afs_session which should
> also work.
>
> The pam_krb5_ccache sets the KRB5CCNAME to force a clean cache, to avoid
> some bugs which Sun may have fixed, then cleans up the cache when the
> session ends.
>
>
>
> Jeff Blaine wrote:
>> [ Thanks to all of you for the previous help, BTW! ]
>>
>> Let's try this with PAM now. Ignore the previous work
>> which ended up working (see messages last week).
>>
>> What works: I can ssh into the server and get krb5 creds
>> (all PAM with sshd-gssapi entries).
>>
>> What doesn't work: I had to enter a password, so ticket
>> forwarding is not working as expected.
>>
>> I'm obviously trying to get a working solution here that
>> does not require any 3rd party workings to at least get
>> this far (yes, the 3rd party pam_afs_session will be used
>> at a later point to get AFS tokens from krb5 creds).
>>
>> Client-side tickets were forwardable and the client-side
>> ssh command was:
>>
>> /usr/bin/ssh -o "GSSAPIDelegateCredentials yes" -o
>> "GSSAPIAuthentication yes" alberta
>>
>> == Log data ==
>> ...
>> debug1: Client offered gssapi userauth with { 1 2 840 113554 1 2 2 }
>> (supported)
>> debug1: Received delegated GSS credentials
>> PAM-KRB5 (acct): debug=1, nowarn=0
>> PAM-KRB5 (acct): no module data for KRB5_AUTOMIGRATE_DATA
>> PAM-KRB5 (acct): no module data
>> PAM-KRB5 (acct): end: Ignore module
>> PAM-KRB5 (setcred): start: nowarn = 0, flags = 0x1
>> PAM-KRB5 (setcred): kmd get failed, kmd=0x0
>> PAM-KRB5 (setcred): end: Can not retrieve user credentials
>> Failed gssapi-with-mic for jblaine from xxx.xx.11.213 port 36762 ssh2
>> ...
>> # A few other failed gssapi-with-mic attempts here (labeled
>> # as unsupported)
>> ...
>> debug1: Storing delegated GSS-API credentials
>> debug1: temporarily_use_uid: 26560/10 (e=0/0)
>>
>> == sshd_config ===
>> ...
>> GSSAPIAuthentication yes
>> GSSAPIKeyExchange yes
>> GSSAPIStoreDelegatedCredentials yes
>> ...
>>
>> == pam.conf ==
>> sshd-gssapi auth requisite pam_authtok_get.so.1
>> sshd-gssapi auth required pam_dhkeys.so.1
>> sshd-gssapi auth sufficient pam_krb5.so.1 debug
>> sshd-gssapi auth required pam_unix_auth.so.1
>> sshd-gssapi account requisite pam_roles.so.1
>> sshd-gssapi account requiredpam_unix_account.so.1
>> sshd-gssapi account requiredpam_krb5.so.1 debug
>> sshd-gssapi session requiredpam_unix_session.so.1
>> sshd-gssapi session requiredpam_krb5.so.1 debug
>>
>>
>> Kerberos mailing list Kerberos@mit.edu
>> https://mailman.mit.edu/mailman/listinfo/kerberos
>>
>>
>
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Now with PAM? Solaris 10 sshd and ticket forwarding
The problem may be in the pam.conf. With sshd-gssapi,
only the PAM session and account routines are called, and
you don't use the pam_krb5. The sshd stores the credentials
for you,not PAM.
We use this in /etc/pam.conf, (but all uncommented.)
Try with just the 3 uncommented lines.
sshd-gssapi account requisite pam_roles.so.1
sshd-gssapi account required pam_unix_account.so.1
#sshd-gssapi account required /krb5/lib/pam_krb5_ccache.so.1
ccache=/tmp/krb5cc_%u_%p
sshd-gssapi session required pam_unix_session.so.1
#sshd-gssapi session required /krb5/lib/pam_afs2.so.1
#sshd-gssapi session required /krb5/lib/pam_krb5_ccache.so.1 clean
The pam_afs2 is the local equivelent of pam_afs_session which should
also work.
The pam_krb5_ccache sets the KRB5CCNAME to force a clean cache, to avoid
some bugs which Sun may have fixed, then cleans up the cache when the
session ends.
Jeff Blaine wrote:
> [ Thanks to all of you for the previous help, BTW! ]
>
> Let's try this with PAM now. Ignore the previous work
> which ended up working (see messages last week).
>
> What works: I can ssh into the server and get krb5 creds
> (all PAM with sshd-gssapi entries).
>
> What doesn't work: I had to enter a password, so ticket
> forwarding is not working as expected.
>
> I'm obviously trying to get a working solution here that
> does not require any 3rd party workings to at least get
> this far (yes, the 3rd party pam_afs_session will be used
> at a later point to get AFS tokens from krb5 creds).
>
> Client-side tickets were forwardable and the client-side
> ssh command was:
>
> /usr/bin/ssh -o "GSSAPIDelegateCredentials yes" -o
> "GSSAPIAuthentication yes" alberta
>
> == Log data ==
> ...
> debug1: Client offered gssapi userauth with { 1 2 840 113554 1 2 2 }
> (supported)
> debug1: Received delegated GSS credentials
> PAM-KRB5 (acct): debug=1, nowarn=0
> PAM-KRB5 (acct): no module data for KRB5_AUTOMIGRATE_DATA
> PAM-KRB5 (acct): no module data
> PAM-KRB5 (acct): end: Ignore module
> PAM-KRB5 (setcred): start: nowarn = 0, flags = 0x1
> PAM-KRB5 (setcred): kmd get failed, kmd=0x0
> PAM-KRB5 (setcred): end: Can not retrieve user credentials
> Failed gssapi-with-mic for jblaine from xxx.xx.11.213 port 36762 ssh2
> ...
> # A few other failed gssapi-with-mic attempts here (labeled
> # as unsupported)
> ...
> debug1: Storing delegated GSS-API credentials
> debug1: temporarily_use_uid: 26560/10 (e=0/0)
>
> == sshd_config ===
> ...
> GSSAPIAuthentication yes
> GSSAPIKeyExchange yes
> GSSAPIStoreDelegatedCredentials yes
> ...
>
> == pam.conf ==
> sshd-gssapi auth requisite pam_authtok_get.so.1
> sshd-gssapi auth required pam_dhkeys.so.1
> sshd-gssapi auth sufficient pam_krb5.so.1 debug
> sshd-gssapi auth required pam_unix_auth.so.1
> sshd-gssapi account requisite pam_roles.so.1
> sshd-gssapi account requiredpam_unix_account.so.1
> sshd-gssapi account requiredpam_krb5.so.1 debug
> sshd-gssapi session requiredpam_unix_session.so.1
> sshd-gssapi session requiredpam_krb5.so.1 debug
>
>
> Kerberos mailing list Kerberos@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>
>
--
Douglas E. Engert <[EMAIL PROTECTED]>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
