From a convenience perspective, I want to authenticate as infrequently as possible. However, security requirements suggest that I should be authenticated for all sorts of services. This means that Single Sign On and forwardable authentication credentials would be useful.
Within an individual organisation at least, it is useful and fairly straightforward to have centralised control for authentication services. More and more authorisation and applications services are able to use centralised authentication services such as Kerberos.
This document will demonstrate how to configure a machine running OpenSSH server to use GSSAPI so that users can log in if they have authorised kerberos tickets. This is not the place for extensive explanations about tickets or how to set up the Key Distribution Center(KDC) in the first place or how to build or install the necessary software on various different unixlike systems. Likely, your distribution's package management system can provide you with what you need.
Kerberos
All destination machines should have /etc/krb5.conf modified to allow forwardable tickets:
[libdefaults] default_realm = ALLGOODBITS.ORG forwardable = TRUE [realms] ALLGOODBITS.ORG = { kdc = kerberos.allgoodbits.org } Using kadmin, create a principal for a user:
kadmin> ank <username>@<REALM>
Here the process differs depending upon whether you're using MIT Kerberos (probably) or Heimdal.
MIT
Create a principal for the host:
kadmin> ank -randkey host/<FQDN>@<REALM>
Extract the key for the host principal to a keytab file and locate it correctly on the ssh server:
kadmin> ktadd -k /tmp/<FQDN>.keytab host/<FQDN>
Heimdal
Create a principal for the host:
kadmin> ank -r host/<FQDN>@<REALM>
Extract the key for the host principal to a keytab file and locate it correctly on the ssh server:
kadmin> ext -k /tmp/<FQDN>.keytab host/<FQDN>@<REALM>
SSH
Then we need to take the keytab file into which you extracted the key for the host principal and copy it to the location on the ssh server where sshd will look for it, probably /etc/krb5.keytab.
We need to configure sshd_config(5). The important options start with GSSAPI, not to be confused with the Kerberos options which are merely for KDC-validated password authentication; the GSSAPI method allows authentication and login based upon existing tickets. In other words, the "Kerberos" method requires you to enter your password (again), GSSAPI will allow login based on upon the tickets you already have.
sshd_config:
GSSAPIAuthentication yes GSSAPICleanupCredentials yes PermitRootLogin without-password
ssh_config:
GSSAPIAuthentication yes GSSAPIDelegateCredentials yes
PAM
Linux Pluggable Authentication Modules(PAM) provide a common framework for authentication/authorisation for applications.
/etc/pam.d/common-account:
account sufficient pam_krb5.so use_first_pass
/etc/pam.d/common-auth:
auth sufficient pam_krb5.so use_first_pass
/etc/pam.d/common-password:
password sufficient pam_krb5.so
/etc/pam.d/common-session:
session optional pam_krb5.so
This is sufficient to allow OpenAFS based home directories because although AFS uses Kerberosv4, MIT Kerberos does 5 to 4 ticket conversion on the fly.
Troubleshooting
- As with anything concerned with kerberos, make sure you have NTP and DNS working properly before you even start.
- ssh -v can give you a lot of valuable information.
- read your logs.