openindiana - set up ssh with kerberos authentication

This time, we will build a base kerberos setup. At the end, you will be able to login into another machine using kerberos only.

You need the following things, to make kerberos work:

I will explain this setup on an openindiana system with 2 zones. kerberosp1 will be my kerberos machine and sshp1 will be my ssh server with kerberos support.

setup of kerberos

The setup of kerberos was pretty easy, after reading 3 tutorials about it. The essential part here is to decide, how the realm and the admin account should be called.

To start the setup, call kdcmgr. At first, it asks your realm, which you should name like your domain. After that, you have to generate an admin principal.A principal is like an account for a user or admin. But it’s also used for services. I named mine kerberosp1/admin. Give it a safe password and you are done.

Now you should have an populated /etc/krb5/ directory. Open the file kdc.conf in that directory and search for max_life. It was set to 8 hours for me, which was too long. Adjust the value to 4h or 16h, like you want. I did the same with max_renewable_life.

Edit: You should add the following option in the realms section to your realm.

kpasswd_protocol = SET_CHANGE

Kerberos uses a separate protocol for changing the password of principals. A RPC like protocol is used in the solaris version and microsoft has another one too. So the only option compatible on all is SET_CHANGE. But to make things worse, the solaris default does not even work in an internal network. So just add this entry and save some stress from trying to find out, why this is not working.

setting up some accounts

To use the kerberos service, check first, if the kdc is running and start it, if it’s not. For openindiana, the check is

svcs krb5kdc

which should return online.

After that, as root start the kerberos shell with kadmin.local. This is a management shell to create, delete and modify principals. Here we are going to create some policies. With these, we can set some minimal standards, like the minimum password length.

I created three policies. An admin, user and a service policy. These got the following settings:

This sets some password limitations for every principal group I have. minclasses is used for different types of characters. There are lower case, upper case, numbers, punctation and other characters. The create a new policy use the command addpol or add_policy with -minlength and -minclasses. You can simply type the command to get some help or read the man page.

After creating the policies, we have to create some principals. First, we should create one for ourselves. You can do this with the command addprinc or add_principal. Give it a policy with the argument -policy and a name. You will have to input a password for this principal according to the policies.

You can use this scheme to create user accounts too. For that, you can generate a password for them with the program pwgen. It’s pretty helpful and can generate pretty complex passwords, so that should be best.

Now we need a principal for our ssh server. The name of this principal should be host/name_of_service.your.domain.name, so in my case, it is host/sshp1.prod.lan. But I did not want to generate any password and added the argument -randkey which generates a password according to the policies we set.

Now we have to export the key of the last principal into a keytab file, that can be read by the service, which wants to use it. This is done with the command ktadd like this

ktadd -k /etc/krb5.keytab host/sshp1.prod.lan

This generates our file in /etc/krb5.keytab. Copy this file into the kerberos directory (on openindiana it’s /etc/krb5/) and delete the one on the kerberos host. This is important, as another execution of ktadd will append the next key to that file.

setting up ssh

For making ssh work with kerberos, we need /etc/krb5/krb5.conf and /etc/krb5/krb5.keytab. In the step before, we already moved the krb5.keytab. We can copy the krb5.conf from the kerberos server to the ssh server.

Now you can start the ssh deamon.

try to log in

For the test, we will try to connect to the ssh host from the kerberos host. So start a shell on the kerberos server and type kinit. This should ask for your password. If it was correct, klist should show you, that you have been granted a ticket.

Now try to open a ssh session to the server, with -v set for more informations and it should work.

problems that can occur

no default realm

The is the message

kinit(v5): Configuration file does not specify default realm when parsing name gibheer

which hints, that your /etc/krb5/krb5.conf is missing.

client/principal not found

The message

kinit(v5): Client 'foo@PROD.LAN' not found in Kerberos database while getting initial credentials

is a hint, that you forgot to add the principal or that your username could not be found. Just add the principal with kadmin and it should work.

ssh does not use kerberos

If ssh does not want to use kerberos at all, check for the GSSAPI options. These should be enabled by default, but can be disabled. If that’s the case, add the following line to your sshd_config.

GSSAPIAuthentication yes

After a restart, ssh should use kerberos for authentication.

links

one last word

I have one last word for you: Kerberos does not do authorization!

That means, that kerberos can not say, if one principal is allowed to use a service or not. It just manages the authentication for you. If you want to manage the access, there are some possibilities for that. One is to use ldap, often used in conjunction with kerberos. Or you manage the passwd files or any other file yourself or you use a service like chef or puppet.

changelog