I would recommend changing your common-auth so that pam is not required. Mine reads like this:
#auth required pam_unix.so nullok_secure auth sufficient pam_krb5.so auth sufficient pam_unix.so nullok try_first_pass auth required pam_deny.so
So I have pam_unix.so commented out where it's defined as required and include it on another line as sufficient. That may be what's blocking you.
I'm running Debian Sarge on several machines and I'm able to ssh to any of them using MIT Kerberos for authentication. Most of my user accounts on the servers were created without passwords so the Krb5 ticket is the only way to get on the machine (root ssh access is denied).
D.
David Kuhl Parity Systems [EMAIL PROTECTED] -----------------------
Wes Chow wrote:
I'm still having the same problem...
I've copied your sshd_config:
# To change Kerberos options KerberosAuthentication yes #KerberosOrLocalPasswd yes #AFSTokenPassing no KerberosTicketCleanup yes
# Kerberos TGT Passing does only work with the AFS kaserver or krb5 KerberosTgtPassing yes
#GSSAPI authentication GSSAPIAuthentication yes GSSAPIKeyExchange yes GSSAPIUseSessionCredCache yes
installed libpam-krb5, set CLOSE_SESSIONS as yes, and put this in my common-auth:
auth sufficient pam_krb5.so auth required pam_unix.so nullok_secure
All the keytab stuff was set up from before. In my original email, sent a while back, I also mentioned that I can used kerberized telnet just fine, so the keytab stuff should be correct. It's specifically PAM stuff that isn't working. This is all Debian Sarge...
But maybe I can work around the system... the principle reason why I'm interested in ssh is because I'd like a X to be automatically exported. If there's some way to do that automatically with Kerberized rsh or telnet, then I'd be happy with that too. The only reason why I'm fiddling with PAM is to get the automatic X with ssh. We rarely log into these machines through the console, and if then, only as root.
I guess my question is what's the recommended way to export X automatically through a remote login with the fewest security implications?
Thanks, Wes
________________________________________________ Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
