Nicolas et al,
SSHD server
~:alberta> uname -a
SunOS alberta.foo.com 5.10 Generic_127111-01 sun4u sparc SUNW,Ultra-5_10
~:alberta>
~:alberta> sudo /usr/lib/ssh/sshd -p -o
"GSSAPIStoreDelegatedCredentials yes" -o "GSSAPIKeyExchange ye
Solved.
Had to force client-side "-o GSSAPIStoreDelegatedCredentials yes"
even though it was not defined anywhere as "no" (although probably
a default for some reason).
Jeff Blaine wrote:
> Nicolas et al,
>
> SSHD server
>
> ~:alberta> u
[ 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,
Jeff Blaine wrote:
> Solved.
>
> Had to force client-side "-o GSSAPIStoreDelegatedCredentials yes"
> even though it was not defined anywhere as "no" (although probably
> a default for some reason).
Are you sure that was it? GSSAPIStoreDelegatedCredentials is a server side
option and defaults to
Sorry, I meant to say "GSSAPIDelegateCredentials yes"
on the client side.
Douglas E. Engert wrote:
>
>
> Jeff Blaine wrote:
>> Solved.
>>
>> Had to force client-side "-o GSSAPIStoreDelegatedCredentials yes"
>> even though it was not defined anywhere as "no" (although probably
>> a default for so
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 a
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
On Mon, Nov 05, 2007 at 12:06:14PM -0500, Jeff Blaine wrote:
> Solved.
>
> Had to force client-side "-o GSSAPIStoreDelegatedCredentials yes"
> even though it was not defined anywhere as "no" (although probably
> a default for some reason).
The manpage (ssh_config(4)) says:
GSSAPIDelegateCre
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.
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 whe
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
I have built the krb5-1.6.2 on Solaris 10 Ultra 25 machine successfully.
When I run make for the krb5-1.6.3 on the same solaris 10 Ultra 25
machine. I got two error messages, and the make aborted.
make: Fatal error: Command failed for target `libss.a'
Current working directory /u1/krb5-1.6.3/s
On Nov 5, 2007, at 15:14, Cheng, Xian Lin wrote:
> I have built the krb5-1.6.2 on Solaris 10 Ultra 25 machine
> successfully.
> When I run make for the krb5-1.6.3 on the same solaris 10 Ultra 25
> machine. I got two error messages, and the make aborted.
>
>
>
> make: Fatal error: Command failed f
13 matches
Mail list logo
