Here are some general hints for installing and configuring Kerberos on another UNIX system for which we don't have specific instructions.
Please note that other UNIX operating systems are not supported by IT Services. We provide these instructions as part of our support for Kerberos on campus, but we will not be able to help with issues specific to those operating systems.
Clients and basic configuration
First, look to see if your operating system either comes with Kerberos or has basic Kerberos packages available. Most do. They may be installed in an unusual path. Look through the system for kinit, klist, and kdestroy binaries.
If the system doesn't come with Kerberos, you can probably build and install a third-party Kerberos implementation in /usr/local or another similar path. See if either MIT Kerberos or Heimdal supports your operating system.
Once you have Kerberos installed, you will need to install an /etc/krb5.conf file with the appropriate configuration for Stanford's Kerberos realm. You can download the sitewide version. If you built Kerberos yourself, you may need to put this file somewhere other than /etc/krb5.conf. See the documentation of the Kerberos implementation that you installed.
If you are using AFS on this system, check for an openafs-krb5 package that provides aklog. If you cannot find one, you will need to compile aklog. aklog comes with the OpenAFS source distribution, available from the OpenAFS web site. If your operating system provides Kerberos packages, there is usually a krb5-devel or similar package that contains the necessary development environment for building aklog. Otherwise, you will probably have to install a third-party Kerberos implementation to get the necessary development environment and libraries.
If the SSH client that comes with the system doesn't support GSSAPI (see the ssh_config man page), you may be able to download portable OpenSSH. It contains GSSAPI support. You will need to have a Kerberos development environment installed to build that support.
Kerberos rlogin, rsh, and rcp clients may be provided with the Kerberos packages of your operating systme (most likely for Linux or BSD systems). Otherwise, if you want to use them, you will need to download and compile a third-party Kerberos implementation.
First, before enabling remote logins with Kerberos, you should make sure
that all accounts on your system with logins enabled either match the
SUNet IDs of those users or contain a
.k5login file (which should
be empty if Kerberos logins aren't permitted for that account). By
default, the servers that accept Kerberos logins will allow a user to log
in to an account if their Kerberos principal matches the account name.
The presence of a
.k5login file overrides this logic and only
principals listed in that file will be permitted to log in to that
See UNIX Kerberos Commands in the
user guide for more information on creating a
To authenticate connections to your system using Kerberos, the system needs its own Kerberos service principal and a keytab for that principal. The service principal is an account in Kerberos, similar to a SUNet ID but for a service instead of a person. The keytab is, in essence, the password for that account stored in a file on your system. For information on how to obtain a service principal, see Downloading Keytabs with Wallet.
If your system comes with portable OpenSSH, it probably has GSSAPI support. You can enable that support by adding:
to the sshd_config file, wherever that's located on your system. Otherwise, you can download portable OpenSSH. You will need a Kerberos development environment to build SSH with that support.
To allow users to log in with a username and password but check that password against Kerberos and use it to acquire Kerberos tickets, see the next section.
Servers for Kerberos rlogin, rsh, and rcp clients may be provided with the Kerberos packages of your operating systme (most likely for Linux or BSD systems). Otherwise, if you want to use them, you will need to download and compile a third-party Kerberos implementation. Once the binaries are installed, you normally run them by adding something like:
eklogin stream tcp nowait root /usr/local/sbin/klogind klogind -5ec
kshell stream tcp nowait root /usr/local/sbin/kshd kshd -5ec
to /etc/inetd.conf and (if necessary) something like:
kshell 544/tcp kcmd krcmd
The only good way to support Kerberos authentication for local logins is via PAM. Most UNIX systems now support PAM, and many include a Kerberos PAM module as part of the operating system. See the PAM documentation that came with your operating system for information on how to configure a Kerberos PAM module.
If your system supports PAM but doesn't provide a Kerberos PAM module, look at pam-krb5. It will build with either MIT Kerberos or Heimdal and should be fairly portable, although PAM implementations can vary widely from system to system and it may need some help to work on your system.