SSH Single Sign On (SSO) for Ubuntu 12.04 using a Windows 2008 R2 / 8 Server Beta AD domain

In my previous post I discussed how to join a Ubuntu 12.04 server to a Windows AD domain (so far I've tried it for both windows 2008 R2 and Windows 8 Server Beta AD domains)

 

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.

1. Install auth-client-config an kerberos libraries for PAM:
   

   sudo apt-get install auth-client-config libpam-krb5

2. Configure PAM for Keberos authentication:

   sudo auth-client-config -t pam-password -p kerberos_example

That is it.

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 crucial.

In order to test SSO from Putty, you need to ensure that you don't connect via IP address and that you set the auto-login username to a valid domain user, see below:

In order to test SSO from another Linux box do the following steps (note that depending on your distro you might have to install some packages):

1. Get Kerberos ticket:

   kinit domainuser@TEST.ORG

2. Login:

   ssh servername -l 'test\domainuser'

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):

sudo /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:

sudo 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.

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.

SSH Single Sign On for CentOS 6.2 or RHEL 6.0 using a Windows 2008 AD domain

In one of my previous posts I discussed how to join a CentOS 6.2 server to a Windows 2008 AD domain. There was one thing that wasn't working and that really, and I mean, REALLY annoyed me and this was: single sign on, i.e. using SSH to login to another server in the domain without being prompted for your password again.

After a lot of head banging, cursing and wondering why oh why had I decided to embark in such a doomed enterprise, I managed to get it working. I assume that you have followed my previous post on how to join a CentOS 6 (RHEL 6 works too) and that you have two linux machines that have joined the domain. A second machine is only needed for testing purposes, you could use putty instead. I needed the second machine for other purposes, so that is the route I chose. I have also tested it with putty and it does work as well.

Here is the list of steps needed:

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:

   ktpass -princ host/adtest.my.org@MY.ORG -mapuser MY\adtest$  -pass Passw0rd123 -ptype KRB5_NT_PRINCIPAL -crypto All -out adtest.keytab


2. Copy adtest.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.
3. If your server doesn't have a keytab file (/etc/krb5.keytab), then you can just move adtest.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. [Optional] Limit encryption to RC4-HMAC, by editing the kerberos configuration file /etc/krb5.conf and adding the following to the [libdefaults] directive:

default_tkt_enctypes=rc4-hmac
default_tgs_enctypes=rc4-hmac
permitted_enctypes =rc4-hmac

5. Restart the OpenSSH daemon:

   service sshd restart

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

Host *.my.org
GSSAPIAuthentication yes
GSSAPIDelegateCredentials yes

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

klist

Ticket cache: FILE:/tmp/krb5cc_10000_TjT7rk
Default principal: linuxuser@MY.ORG

Valid starting     Expires            Service principal
02/28/12 17:41:06  02/29/12 03:39:31  krbtgt/MY.ORG@MY.ORG
        renew until 02/29/12 03:41:06

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

    ssh adtest5.my.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 don't have a 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.