How To
Summary
This document will describe how to get SSH Kerberos single sign-on working.
Steps
This document assumes:
a) You have two AIX systems that are configured as Kerberos clients to the same KDC
b) The KDC is running IBM NAS software. If you are using something different as the KDC, the steps are the same, except the creation of principals and keytabs will be different
c) A user exists on the target system that has the same name as the Kerberos principal you are using - for example, the target system has a user called 'krbusr' and there is a Kerberos principal called 'krbusr'
d) The Kerberos realm being used is LAB.EXAMPLE.COM
e) The date/time is synced up between the two systems; too much clock skew will cause this to fail
Steps to take:
1) On the source system (labsys91.austin.ibm.com), in /etc/ssh/ssh_config, add:
GSSAPIAuthentication yes
GSSAPIDelegateCredentials yes
2) On the target system (labsys59.austin.ibm.com), in /etc/ssh/sshd_config, add:
GSSAPIAuthentication yes
GSSAPICleanupCredentials yes
Restart sshd after modifying sshd_config.
For steps 1 and 2, if the 'source' and 'target' systems may switch roles, then modify ssh_config and sshd_config on both systems.
3) On your KDC, create host principals for each of the systems involved:
host/labsys91.austin.ibm.com@LAB.EXAMPLE.COM
host/labsys59.austin.ibm.com@LAB.EXAMPLE.COM
If using IBM NAS as your KDC, this can be done in the kadmin utility with:
addprinc -randkey host/labsys59.austin.ibm.com
addprinc -randkey host/labsys91.austin.ibm.com
4) Create keytabs for each of these principals. If using IBM NAS, this can be done in kadmin with:
ktadd -k /tmp/lab59.keytab host/labsys59.austin.ibm.com
ktadd -k /tmp/lab91.keytab host/labsys91.austin.ibm.com
5) Copy these keytabs to their respective systems and load them into /etc/krb5/krb5.keytab using the ktutil tool:
# ktutil
ktutil: rkt /tmp/lab91.keytab
ktutil: wkt /etc/krb5/krb5.keytab
ktutil: quit
6) If using local lookups in /etc/hosts for your hostnames, make sure FQDN is listed before short host name
7) On your source system, obtain a Kerberos credential with kinit:
/usr/krb5/bin/kinit krbusr
The user that runs kinit on the source system does not have to have the same username as that of the Kerberos principal and target user.
8) Perform the ssh to the user on the target system that matches the Kerberos principal name, and it should work:
ssh krbusr@labsys59
If you want your Kerberos credential to be forwarded to the target system so that you still have the credential after login, you must make it forwardable. This can be done by adding the '-f' flag onto the kinit command, but the easier way is to add the 'forwardable = true' option to krb5.conf in the libdefaults section. With that added, any Kerberos credential will be forwardable by default, as long as the KDC allows it. This method will be best if you are using Kerberos integrated login like KRB5LDAP or KRB5files, so the credential generated automatically during login will be forwardable.
Document Location
Worldwide
[{"Type":"MASTER","Line of Business":{"code":"LOB08","label":"Cognitive Systems"},"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SWG10","label":"AIX"},"ARM Category":[{"code":"a8m0z000000cvzkAAA","label":"Security-\u003EUser\/Group\/Password Management-\u003EKERBEROS\/NAS"}],"ARM Case Number":"","Platform":[{"code":"PF002","label":"AIX"}],"Version":"5.3.0;6.1.0;7.1.0;7.2.0;7.3.0"}]
Was this topic helpful?
Document Information
Modified date:
08 July 2025
UID
ibm17239239