Computer Laboratory

Kerberos use under Unix


Kerberos is an authentication system which can be used in many ways.

For local discussion, details and management info, see the WiKi.

Simple use

If recently logged in at the console of a Lab workstation with a fairly current Linux distribution it should normally be possible to connect to a "kerberos" machine (such as greta in this example) using commands such as

$ cl-xon greta
$ slogin greta -K -X
Linux 2.6.28-9-generic #31-Ubuntu SMP Wed Mar 11 15:43:49 UTC 2009 x86_64

If that fails

$ cl-xon greta
Permission denied (publickey,gssapi-keyex,gssapi-with-mic,hostbased).
$ slogin greta -K -X
Permission denied (publickey,gssapi-keyex,gssapi-with-mic,hostbased).

or you are on some other machine, then first login to as usual, run the command kinit (it will ask for your password), then try the commands as above.

There are many other ways to use ssh to connect to such machines, but there are so many cases that it gets fairly complicated, as can be seen below.


We have been (ab)using Kerberos for some time as an authentication system, by causing the login to obtain a Kerberos ticket which was not used, but the fact that one was returned indicated that the user could authenticate. We added Kerberos as an authentication method for ssh login, and finally started actually using the ticket to access files using NFS v3's sec=krb5 access. This final stage has brought various problems with it, as any ssh attempt without a forwarded Kerberos ticket is unable to inspect ~/.ssh/authorized_keys to see whether the access should be permitted, as filer access needs a ticket.

ssh uses

ssh access can be ssh user key or Kerberos based, with or without access to the filer, and with or without X11 forwarding, although X11 forwarding normally needs filer access.

local access from Kerberos aware WS

The simplest case is a user logging in at the console of a Kerberos aware machine, working for less then 10 hours, then logging out and switching off the machine. It should allow Kerberos auth with filer and X11 access.
If the user stays logged in for more than 10 hours, the ticket might expire. If so, treat as "local access from Kerberos aware server".

local access from Kerberos aware server

If you have not logged in at the console of the machine, a ticket may not be available. A simple test is to run "kinit -R". If it says nothing, the ticket is still valid. If it complains, run kinit to get a new one. It should then allow Kerberos auth with filer and X11 access.

unplanned internet access

Wanting to login to a sec=krb5 host from the internet is one of the cases where a two step login is needed. First login to a Kerberos aware server which is sec=sys (e.g. the time sharing systems slogin*), then treat as "local access from Kerberos aware server".

planned short term internet access

Before use is needed, arrange that a ticket is being refreshed, e.g. "cl-krenew --maxout". This will allow access to elmer until the ticket expires, which is normally a day. To extend this to a week, use "cl-krenew --freshticket --maxout" which requires a password. Access can be Kerberos or user ssh key based, filer access should work without passing a ticket, so X11 forwarding should also be possible. The -K flag should not be needed.

planned internet access (experts)

If cl-update-authorized-keys is used, a local copy of ~/.ssh/authorized_keys can be made, allowing login without filer access, at which point kinit can be run. It is also possible to get X11 forwarding to work.
Both stages need configuration tweaks on the called machine, so is most appropriate for experts connection to their own WS.
Access can be Kerberos or user ssh key based, filer access will not be available initially, so X11 forwarding needs special attention.

PuTTY uses

Windows machines use PuTTY rather than ssh. The quest version of PuTTY can use GSSAPI-with-MIC. Users should be able to install it from the SCCM / SMS "available programs" window (see also "Control Panel -> Get Programs -> Install program" and on 64b machines "View 32bit control panel items". It is also available at \\didcot\swdist\putty\).

The quest version can be used for the cases above which use "-K", and the normal PuTTY can be used in the cases where it isn't needed.

The substantive information is as above, with details of which version is usable in various situations.

local access from Kerberos aware WS

Use the quest version.

unplanned internet access

Use any version to connect to slogin-serv.

planned short term internet access

Use any version.