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:
- 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
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
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
user and a
service policy. These got the following settings:
- minlength 8
- minclasses 3
- minlength 8
- minclasses 2
- 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
-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
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.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
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
After a restart, ssh should use kerberos for authentication.
- setup of kerberos on opensolaris
- MIT kerberos page
- KDC Setup on Solaris
- Kerberos password
- Kerberos policies
- Administrative Guide to Kerberos
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.
- added some explanation to