+++
title = "openindiana - set up ssh with kerberos authentication"
date = "2011-11-12T21:45:01+00:00"
author = "Gibheer"
draft = false
+++

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:

* a working dns server
* 2 servers

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:

* admin
  * minlength 8
  * minclasses 3
* user
  * minlength 8
  * minclasses 2
* service
  * minlength 12
  * minclasses 4

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
=====

* [setup of kerberos on opensolaris](http://www.linuxtopia.org/online_books/opensolaris_2008/SYSADV6/html/setup-148.html)
* [MIT kerberos page](http://web.mit.edu/kerberos/krb5-1.5/krb5-1.5.4/doc/krb5-admin/krb5_002econf.html)
* [KDC Setup on Solaris](http://wiki.creatica.org/cgi-bin/wiki.pl/Kerberos_KDC_server_on_Solaris)
* [Kerberos password](http://fnal.gov/docs/strongauth/princ_pw.html#46115)
* [Kerberos policies](http://pig.made-it.com/kerberos-policy.html)
* [Administrative Guide to Kerberos](http://techpubs.spinlocksolutions.com/dklar/kerberos.html#err_server_not_found)

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](http://wiki.opscode.com/display/chef/Home) or [puppet](http://puppetlabs.com/).

changelog
=========

* added some explanation to `kpasswd_protocol`