Oracle Solaris 10 Kerberized SSH Configuration

If you manage Oracle Solaris 10 machines, you might want to configure your servers to accept Kerberos principals via SSH. The SSH that comes with Solaris 10 does not understand the same configurations as the OpenSSH one does. And Solaris has a little quirk that Linux and BSD don't.

If you don't already have a Kerberos infrastrucutre in place, then the first thing to do is to set one up. Read my other article HOWTO : Kerberos KDC with OpenLDAP 2.4 Back-End and SASL GSSAPI Authentication on CentOS 6.2 to learn how to create a Kerberos realm.

In this example, the Solaris host is called voyager.company.com, the Kerberos realm is COMPANY.COM and the KDC machines are kdc1.company.com & kdc2.company.com.

The second thing to do is simply to install Oracle Solaris 10 1/13 which is the latest version of Solaris 10 available on the Oracle download site. Make sure you have the following packages installed on the Solaris machine :

system      SUNWkdcr                     Kerberos V5 KDC (root)
system      SUNWkdcu                     Kerberos V5 Master KDC (user)
system      SUNWkrbr                     Kerberos version 5 support (Root)
system      SUNWkrbu                     Kerberos version 5 support (Usr)

system      SUNWsshcu                    SSH Common, (Usr)

system      SUNWsshdr                    SSH Server, (Root)

system      SUNWsshdu                    SSH Server, (Usr)

system      SUNWsshr                     SSH Client and utilities, (Root)

system      SUNWsshu                     SSH Client and utilities, (Usr)

Configure the sshd service.

sudo vi /etc/ssh/sshd_config

Notice how I left the various Kerberos and GSSAPI configurations in comments? The idea is to prevent other admins from enabling those. If you do, then the sshd server will refuse to start and the service will be placed in maintenance mode. This is what would happen if you did enable them :

sudo svcadm restart ssh

But sshd would have died. If you looked in the log files, this is what came up :

Feb 22 14:59:18 voyager sshd[503]: [ID 800047 auth.info] Received signal 15; terminating.
Feb 22 14:59:18 voyager svc.startd[11]: [ID 652011 daemon.warning] svc:/network/ssh:default: Method "/lib/svc/method/sshd start" failed with exit status 255.
Feb 22 14:59:18 voyager svc.startd[11]: [ID 652011 daemon.warning] svc:/network/ssh:default: Method "/lib/svc/method/sshd start" failed with exit status 255.
Feb 22 14:59:18 voyager svc.startd[11]: [ID 652011 daemon.warning] svc:/network/ssh:default: Method "/lib/svc/method/sshd start" failed with exit status 255.
Feb 22 14:59:19 voyager svc.startd[11]: [ID 748625 daemon.error] network/ssh:default failed: transitioned to maintenance (see 'svcs -xv' for details)

So, as the log says, we run svcs.

svcs -xv

svc:/network/ssh:default (SSH server)

 State: maintenance since February 22, 2013  2:59:19 PM EST

Reason: Start method failed repeatedly, last exited with status 255.

   See: http://sun.com/msg/SMF-8000-KS

   See: man -M /usr/share/man -s 1M sshd

   See: /var/svc/log/network-ssh:default.log

Impact: This service is not running.

So that points us into another log file. Let's take a look.

cat /var/svc/log/network-ssh:default.log

[ Feb 22 14:59:18 Executing start method ("/lib/svc/method/sshd start") ]

/etc/ssh/sshd_config: line 60: Bad configuration option: KerberosAuthentication

/etc/ssh/sshd_config: line 61: Bad configuration option: KerberosOrLocalPasswd

/etc/ssh/sshd_config: line 62: Bad configuration option: KerberosTicketCleanup

/etc/ssh/sshd_config: line 64: Bad configuration option: GSSAPICleanupCredentials

/etc/ssh/sshd_config: terminating, 4 bad configuration options

There you go! I told you it wouldn't work ;)

To clear the error state, simply use svcadm(1M), fix the configuration file and enable it again. 

sudo svcadm clear ssh

sudo vi /etc/ssh/sshd_config

sudo svcadm enable ssh

And now the SSH daemon is running as the log says :

Feb 22 15:20:31 voyager sshd[8772]: [ID 800047 auth.info] Server listening on 0.0.0.0 port 22.

Once you have the Kerberos realm up and going, connect to the Solaris machine to configure it's Kerberos file.

ssh voyager.company.com
sudo vi /etc/krb5/krb5.conf

Then contact the KDC to create the new Solaris 10 host's principal and add it to the machine's keytab.

sudo kadmin
kadmin> addprinc -randkey host/voyager.company.com@COMPANY.COM
kadmin> ktadd host/voyager.company.com@COMPANY.COM
kadmin> exit

That will have created the /etc/krb5/krb5.keytab file. Should you want to take a look at what's in this file, simply run this command :

sudo klist -ek /etc/krb5/krb5.keytab 

Keytab name: FILE:/etc/krb5/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
   2 host/voyager.company.com@COMPANY.COM (AES-256 CTS mode with 96-bit SHA-1 HMAC) 
   2 host/voyager.company.com@COMPANY.COM (AES-128 CTS mode with 96-bit SHA-1 HMAC) 
   2 host/voyager.company.com@COMPANY.COM (Triple DES cbc mode with HMAC/sha1) 
   2 host/voyager.company.com@COMPANY.COM (ArcFour with HMAC/md5) 
   2 host/voyager.company.com@COMPANY.COM (DES cbc mode with RSA-MD5) 

Alright, now the very Solaris peculiar part of the Kerberos SSH authentication is to create a Kerberos principal to local user connection. This is done with the gsscred(1M) command. In this example, I'm going to link my Kerberos principal drobilla@COMPANY.COM to my local UNIX user drobilla.

sudo gsscred -m kerberos_v5 -a -c David Robillard -n drobilla@COMPANY.COM -u drobilla

You can then check the contents of the Kerberos association database with the same command :

sudo gsscred -l

0401000B06092A864886F7120102020000001464726F62696C6C614043415052494F4E2E434F4D  drobilla        David Robillard

Once this association is made, you can now test the Kerberos authentication of sshd. 

HINT : Do NOT log off from the Solaris machine to test SSH. Use another terminal window. If it fails, at least you still have a valid shell on the Solaris machine to try and fix the problem...

So, from a RedHat or CentOS machine that is already part of the same Kerberos realm, do this to test your Kerberized Solaris SSH server.

kdestroy

kinit

Password: <enter your Kerberos principal's password here>

ssh voyager.company.com

You should be logged in to the Solaris machine with your Kerberos principal. If it works, then the logs will show this :

Feb 22 15:24:39 voyager sshd[8785]: [ID 800047 auth.info] Authorized principal drobilla@COMPANY.COM, authenticated with GSS mechanism kerberos_v5, to: drobilla
Feb 22 15:24:39 voyager sshd[8785]: [ID 800047 auth.info] Accepted gssapi-with-mic for drobilla from 192.168.2.2 port 43205 ssh2

While the Kerberos KDC logs will show this :

Feb 22 15:19:39 kdc1 krb5kdc[3234]: TGS_REQ (8 etypes {18 17 16 5 23 3 2 1}) 10.10.2.2: ISSUE: authtime 1361564246, etypes {rep=18 tkt=18 ses=18}, drobilla@COMPANY.COM for krbtgt/COMPANY.COM@COMPANY.COM

Feb 22 15:19:42 kdc1 krb5kdc[3234]: TGS_REQ (7 etypes {18 17 16 23 1 3 2}) 10.10.1.27: ISSUE: authtime 1361564246, etypes {rep=18 tkt=18 ses=18}, drobilla@COMPANY.COM for host/voyager.company.com@COMPANY.COM

If not, then you will be prompted to enter your password :/

BSD Specific Issue

If you try to ssh to the Solaris Kerberized ssh daemon from a FreeBSD or PC-BSD host, you will be authenticated, but immediately kicked out with not much debug info. The trick to make it work is to change your BSD machine's ssh_config (i.e. NOT the sshd_config). It's the BSD OpenSSH client that must NOT try to delegate the credentials. For some reason it never worked for me (if someone knows why, then please let me know). 

What worked for me was to comment-out this line in the BSD machine's /etc/ssh/ssh_config :

# GSSAPIDelegateCredentials

HTH,

DA+