SSH Single Sign On for CentOS 6.2 or RHEL 6.0 using a Windows 8 Server Beta AD domain

In my previous post, I discussed how to join a CentOS 6.2 server to a Windows 8 Server Beta AD domain and in this post I discuss how to get Kerberos based single sign on working. I have tested this method with an openSSH client from Linux and with Putty from windows.

If testing from Linux, you will need at least two Linux servers that have joined the AD domain as explained in my previous post or one that has joined the domain and another with the ability to get a kerberos ticket from the DC.
If testing with Putty, all that is needed is to add a valid username in the Auto-login username field which can be found in Connection | Data. By valid, I mean a domain user with its Unix attributes set.

1. From the Windows domain controller run the following command, which will create spns and upns. Note that you will need to run it as Administrator. I have also run this command for a fully qualified domain name instead of the hostname (i.e. host/pms3.sma.org) without any notable difference.
   

   ktpass.exe -princ host/pms3@SMA.ORG -mapuser SMA\pms3$ -pass Passw0rd123 -ptype KRB5_NT_PRINCIPAL -crypto All -out c:\pms3.keytab

   
2. Copy pms3.keytab to your linux box, I simply mounted the c drive of the DC on the linux box, but this might not be available to you, see this post for instructions.
3. If your server doesn't have a keytab file (/etc/krb5.keytab), then you can just move pms3.keytab to /etc/krb5.keytab otherwise you will need to merge it, which you can do with the ktutil tool, see this link for instructions.
4. Restart the OpenSSH daemon:

   service sshd restart

5. Configure the OpensSSH client. This will limit SSO to hosts in the domain:

Host *.sma.org
GSSAPIAuthentication yes
GSSAPIDelegateCredentials yes

6. Repeat steps 1 to 5 for the second server if needed.
7. Login to first server with a domain account that has linux attributes set.
8. Ensure that a Kerberos ticket has been issued: 

klist

Ticket cache: FILE:/tmp/krb5cc_0
Default principal: atest@SMA.ORG

Valid starting     Expires            Service principal
05/15/12 15:25:45  05/16/12 01:23:44  krbtgt/SMA.ORG@SMA.ORG
        renew until 05/22/12 15:25:45

9. Open secure shell on second server, which will log you without a prompt for credentials
   

   ssh pms3.sma.org

It is very important that name resolution is working correctly as you could get issues if it doesn't work properly, thus an up to date DNS server is quite useful. If you can't  update your DNS server make sure that your hosts files are up to date with all the server names involved.

If you hit any problems, the simplest way to trouble shoot is to open a debug ssh daemon, which you can do like this (you can add a couple more ds for extra debug info but I think debug1 is all you need):

/usr/sbin/sshd -p 31415 -d

You'll need to allow traffic on port 31415 or the port you choose, which you can easily do by stopping iptables. Clearly this should only be done in servers that are not internet facing. If the server is internet facing then just open port 31415, e.g:

iptables -I INPUT -p tcp --dport 31415 -j ACCEPT

You can connect to this server with:

ssh servername -p 31415 -v

This should tell you what the problem is, e.g:

debug1: Unspecified GSS failure.  Minor code may provide more information
Key table entry not found

This was actually caused by a name resolution problem.