Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have a Kerberos 5 + LDAP configuration in the same server.

They both work well (I assume). Kerberos works fine when asking for a TGT.

The problem comes when I try to login from client1 to client2 via passwordless ssh... It keeps asking me for a password even if I have a valid TGT.

I post some logs and configs.

client1 ssh_config:

Host *

GSSAPIAuthentication yes
GSSAPIDelegateCredentials yes
GSSAPIKeyExchange yes

client2 sshd_config:

GSSAPI options

GSSAPIAuthentication yes
GSSAPICleanupCredentials yes

Kerberos options

KerberosAuthentication yes

Trying to get a TGT from client1:

kinit admin

Password for admin@COLOR-STEMP.COM:

klist

Ticket cache: FILE:/tmp/krb5cc_0
Default principal: admin@COLOR-STEMP.COM

Valid starting Expires Service principal
23/05/13 15:35:45 24/05/13 01:35:45 krbtgt/COLOR-STEMP.COM@COLOR-STEMP.COM
renew until 24/05/13 03:35:45

Trying to ssh from client1 to client2:

Client1 shell output:

ssh admin@client2.color-stemp.com

admin@client2.color-stemp.com's password:

Client2 /var/log/auth:

May 23 15:39:42 CLIENT2 sshd[31486]: Invalid user admin from 192.168.1.173
May 23 15:39:42 CLIENT2 sshd[31486]: Failed none for invalid user admin from 192.168.1.173 port 38326 ssh2

Client1 shell output:

klist

Ticket cache: FILE:/tmp/krb5cc_0
Default principal: admin@COLOR-STEMP.COM

Valid starting Expires Service principal
23/05/13 15:35:45 24/05/13 01:35:45 krbtgt/COLOR-STEMP.COM@COLOR-STEMP.COM
renew until 24/05/13 03:35:45
23/05/13 15:40:24 24/05/13 01:35:45 host/client2.color-stemp.com@COLOR-STEMP.COM
renew until 24/05/13 03:35:45

As you can see, CLIENT2 ssh2 is not even trying to authenticate against the kerberos server. But Kerberos is giving client1 the TGT for client2.

I have checked connection or DNS issues... It is all fine.

Any help? thanks in advance...

UPDATE

@Steve: I have checked /etc/pam.d/sshd and looks like there is no kerberos config there... however this is what I have in nsswitch.conf:

#pre_auth-client-config # passwd: compat
passwd: files ldap
#pre_auth-client-config # group: compat
group: files ldap
#pre_auth-client-config # shadow: compat
shadow: files ldap

With the command pam-auth-update I have selected Kerberos Authentication too.

Thanks...

share|improve this question
    
Have you checked what PAM is trying to use with ssh? at least in CentOS it will use what is in /etc/pam.d/sshd. You may also want to look at your /etc/nsswitch.conf –  Steve Butler May 24 '13 at 4:50
    
I updated the question. Thanks. –  hecstevez May 24 '13 at 13:41
    
What does getent passwd admin say on client2? Is authentication failing because the client2 doesn't think that admin is a valid user? –  84104 May 24 '13 at 16:47
    
getent passwd admin does not shows anything... seems to me that client2 is not even trying to authenticate "admin" user against the kerberos... :-( –  hecstevez May 24 '13 at 20:10

1 Answer 1

client2 does not have an account named admin therefore all attempt to authenticate to that non-existent account will fail. sshd isn't going to bother doing GSSAPI for an account that doesn't exit.

If this is account is supposed to exist locally, you need to create it with useradd. If it exists in LDAP, then make sure you nss-ldap/nss-ldapd is appropriately configured (usually /etc/ldap.conf).

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.