Openssh, kerberos and Solaris 10
weiler at soe.ucsc.edu
Wed Aug 9 12:36:30 EDT 2006
> 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
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. :)
> 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 ...
More information about the Kerberos