Openssh, kerberos and Solaris 10

[Erich Weiler]

> You fundamentally misunderstand how network authentication and
> credential forwarding work.

No, I think I do understand it.  All you have written below are steps I 
have taken and am sorted with.  Perhaps I'm not making myself very clear 
in describing the problem I'm having (which I can certainly believe).

> PAM is orthogonal to your problem.

I am getting credentials through PAM.  That much is working.  My 
problem, very specifically, is that:

1: I want SSH to automatically forward my krb5 credentials when I SSH 
into another machine using public keys.

2: I don't want to use Sun SSH; I would rather use OpenSSH.  The reasons 
for this are not applicable to this discussion.

3: OpenSSH can't forward Kerberos credentials without actually being 
compiled against some sort of GSS-API, which I can't seem to do under 
Solaris.

 From what others have said, I'm out of luck in this regard.  Unless I 
compile MIT Kerberos as a standalone package and compile OpenSSH against 
that, I cannot hope to enable OpenSSH krb5 cred forwarding.  But I have 
reasons why I'd like to stick with Solaris SEAM.  Call me picky.  :)

ciao, erich

> 
> In order to use network authentication you first need credentials.  You
> acquire these using kinit(1) or when you login first using a PAM-aware
> login application whose PAM stack is configured to use pam_krb5(5).
> 
> (This also works with keylogin(1) and pam_dhkeys(5), if you use NIS+.)
> 
> Next you use telnet(1), ftp(1), ssh(1), etcetera, with appropriate
> options.  The server has to have acceptor credentials, i.e., a
> host-based principal name for the service 'host' and valid keytab
> entries for these.
> 
> (Again, something similar goes for NIS+/DH.)
> 
> The client and server should negotiate the use of network authentication
> and the client should delegate credentials if a) you have forwardable
> tickets, b) use the appropriate option.
> 
> PAM barely enters the picture on the server-side, and you should not be
> prompted for any passwords.
> 
> So, what are you doing wrong?
> 
> Have you got a TGT on the client?  Is it forwardable?  See the kinit(1)
> man page and post klist(1) (klist -fea) output.
> 
> Does your server have a keytab file?  klist -ke please.  Are those
> keytab entries valid?  You can check this by doing something like:
> 
> # kinit -c /tmp/xyz123 -k host/<server.fqdn>
> # klist -fea -c /tmp/xyz123
> # kdestroy -c /tmp/xyz123
> 
> Now, if you address these issues and still have problems then ssh -vvv
> and sshd -ddd output may be useful.
> 
> # /usr/lib/ssh/sshd -dddp 2222
> ...
> 
> 
> % ssh -p 2222 ...
> ...
> 
> Cheers,
> 
> Nico