Kerberizing Leopard's Remote Login (built-in SSH) service

0. Introduction

Enabling Kerberos/GSSAPI support in Leopard’s Remote Login (SSH) service is straightforward. As Leopard’s Remote Login is built using OpenSSH, most of what is described here applies perfectly to other flavors of UNIX.

Kerberos/GSSAPI authentication allows for Single Sign-On capabilities in OpenSSH in such a way that it makes very convenient to work with or manage multiple machines while only having to authenticate to the network every certain amount (Kerberos uses a form of cached credentials that expire within hours, typically). In this document I describe how to enable support for Kerberos/GSSAPI authentication to Leopard’s implementation of OpenSSH. Leopard includes many of the tools from the MIT’s implementation of Kerberos, so this makes the whole process even easier.

The process consists on:

  1. Creating the Kerberos principal
  2. Creating /etc/krb5.conf
  3. Adding the Kerberos principal to the keytab file
  4. Reconfiguring OpenSSH to support Kerberos authentication
  5. Restarting OpenSSH
  6. Enabling Kerberos authentication on OpenSSH clients
  7. Testing

1. Creating the Kerberos principal

When a Kerberized SSH client tries to authenticate to a Kerberized OpenSSH service, the client will request a Kerberos service ticket for that specific OpenSSH service. The Kerberos service ticket contains, among other things, a shared secret (for example, a 3DES private key) that has to be distributed to both the client and the server, called Kclient,server. The KDC will generate such shared secret and will encrypt it twice. Once, with a shared secret between the KDC and the client principal, called KKDC,client, and another one with a shared secret between the KDC and the server principal, KKDC,server.

In this step, we will create the Kerberos principal that represents the OpenSSH server and consequently its shared secret, KKDC,server. Later on, we will upload this shared secret to the OpenSSH server and install it into the Keytab file, so that the OpenSSH server can access it and use it to decrypt the user’s service ticket in order to retrieve the shared secret, Kclient,server.

$ kadmin
Authenticating as principal alice/admin@LAN with password.
Password for alice/admin@LAN:
kadmin:  addprinc -randkey host/ssh.lan
WARNING: no policy specified for host/ssh.lan@LAN; defaulting to no policy
Principal "host/ssh.lan@LAN" created.

NOTE: If you are logged in as root into the KDC, you can use kadmin.local instead of kadmin if you prefer, as the former doesn’t require any authentication (being able to run it as root is enough to prove yourself authorized).

The Kerberos principal associated with the OpenSSH has been created, the shared secrets generated, stored and protected by the stash key. We can check the status of the principal using the following command:

kadmin:  getprinc host/ssh.lan
Principal: host/ssh.lan@LAN
Expiration date: [never]
Last password change: Thu Dec 06 19:42:50 CET 2007
Password expiration date: [none]
Maximum ticket life: 0 days 10:00:00
Maximum renewable life: 7 days 00:00:00
Last modified: Thu Dec 06 19:42:50 CET 2007 (root/admin@LAN)
Last successful authentication: [never]
Last failed authentication: [never]
Failed password attempts: 0
Number of keys: 2
Key: vno 5, Triple DES cbc mode with HMAC/sha1, no salt
Key: vno 5, DES cbc mode with CRC-32, no salt
Attributes:
Policy: [none]
kadmin:  exit

Now that the principal has been created, we can move onto the next step.

2. Creating /etc/krb5.conf

One of the requirements for Kerberizing OpenSSH server is configuring the Kerberos libraries via /etc/krb5.conf. These libraries are used by the OpenSSH server, kpasswd, the OpenSSH client and tools like kadmin or kinit.

This configuration file will also allow us to connect to the Kerberos administration server remotely by using kadmin, in order to download the OpenSSH shared secret. In my case, /etc/krb5.conf looks like this:

[libdefaults]
        default_realm = LAN
        dns_fallback = "no"
        default_tgs_enctypes = des-cbc-crc
        default_tkt_enctypes = des-cbc-crc

[realms]
        LAN = {
                kdc = kdc.lan:88
                admin_server = kdc.lan:749
        }

[domain_realm]
        .lan = LAN

[login]
        krb4_convert = true
        krb4_get_tickets = false

3. Adding the Kerberos principal to the keytab file

root@ssh.lan:# kadmin
Authenticating as principal root/admin@LAN with password.
Password for root/admin@LAN:
kadmin:  ktadd -k /etc/krb5.keytab host/ssh.lan@LAN
Entry for principal host/ssh.lan@LAN with kvno 7,
 encryption type Triple DES cbc mode with HMAC/sha1 added to
 keytab WRFILE:/etc/krb5.keytab.
Entry for principal host/ssh.lan@LAN with kvno 7,
 encryption type DES cbc mode with CRC-32 added to
 keytab WRFILE:/etc/krb5.keytab.

This will add the OpenSSH shared secret to the Kerberos /etc/krb5.keytab file. We need to add the shared secrets to this file properly, as Leopard has a built-in KDC service and machine-specific shared secrets in this file that are used, among others, by the Screen Sharing service, the AFP service and the SAMBA service.

To check that OpenSSH shared secret was added to the keytab file, we use ktutil to read and display the contents of the Keytab file:

root@ssh.lan:# ktutil
ktutil:  rkt /etc/krb5.keytab
ktutil:  list
slot KVNO Principal
---- ---- ---------------------------------------------------------------------
   1    3 afpserver/LKDC:SHA1.E803840ADEAA3E91BF895E969F56FEDFF321BDD5@LKDC...
   2    3 afpserver/LKDC:SHA1.E803840ADEAA3E91BF895E969F56FEDFF321BDD5@LKDC...
   3    3 afpserver/LKDC:SHA1.E803840ADEAA3E91BF895E969F56FEDFF321BDD5@LKDC...
   4    3 cifs/LKDC:SHA1.E803840ADEAA3E91BF895E969F56FEDFF321BDD5@LKDC...
   5    3 cifs/LKDC:SHA1.E803840ADEAA3E91BF895E969F56FEDFF321BDD5@LKDC...
   6    3 cifs/LKDC:SHA1.E803840ADEAA3E91BF895E969F56FEDFF321BDD5@LKDC...
   7    3 vnc/LKDC:SHA1.E803840ADEAA3E91BF895E969F56FEDFF321BDD5@LKDC...
   8    3 vnc/LKDC:SHA1.E803840ADEAA3E91BF895E969F56FEDFF321BDD5@LKDC...
   9    3 vnc/LKDC:SHA1.E803840ADEAA3E91BF895E969F56FEDFF321BDD5@LKDC...
  10    7                      host/ssh.lan@LAN
  11    7                      host/ssh.lan@LAN

Once installed in the keytab file, OpenSSH will be able to access the shared secret, KKDC,server used to decrypt Kerberos service tickets shown by clients.

  • 4. Reconfiguring OpenSSH to support Kerberos authentication
  • It is also necessary to change OpenSSH’s server configuration file, /etc/sshd_config to explicitly enable Kerberos/GSSAPI authentication. To achieve this, modify /etc/sshd_config file and add the following lines (by default they are either uncommented or disabled):

    # GSSAPI options
    GSSAPIAuthentication yes
    GSSAPICleanupCredentials yes
    

    5. Restarting OpenSSH

    To last step on the server side requires that we restart the OpenSSH service so the previous changes are taken into effect:

    root@ssh.lan:# launchctl
    aunchd% stop com.openssh.sshd
    launchd% start com.openssh.sshd
    

    6. Enabling Kerberos authentication on OpenSSH clients

    Some OpenSSH clients have Kerberos authentication disabled by default. The easiest way to enable Kerberos/GSSAPI authentication in clients is by adding the following directives to $HOME/.ssh/config:

    Host *
            Protocol 2
            GSSAPIAuthentication yes
            GSSAPIKeyExchange yes
            GSSAPIDelegateCredentials no
            GSSAPITrustDns no
    

    This will enable Kerberos/GSSAPI authentication on the client side. The fact that Kerberos/GSSAPI authentication succeeds depends on several factors, like the user having a valid Kerberos TGT, the remote server having Kerberos/GSSAPI authentication enabled, and that the clocks on both the client and server machines are synced (most implementations refuse Kerberos/GSSAPI authentication if the clocks differ more than 5 minutes).

    7. Testing

    First, we need to get a TGT from the Kerberos KDC:

    $ kinit
    Please enter the password for falfaro@LAN:
    

    To check that it worked, we list the tickets available to us, and make sure we see a ticket valid for service krbtgt/*:

    $ klist
    Kerberos 5 ticket cache: 'API:Initial default ccache'
    Default principal: falfaro@LAN
    
    Valid Starting     Expires            Service Principal
    12/06/07 18:06:26  12/07/07 04:06:26  krbtgt/LAN@LAN
    	renew until 12/13/07 18:06:26
    

    Now, let’s try to log in into the OpenSSH server. Kerberos/GSSAPI authentication should be negotiated, as shown by the debugging information:

    core2:~ falfaro$ ssh -v solana
    OpenSSH_4.5p1, OpenSSL 0.9.7l 28 Sep 2006
    debug1: Reading configuration data /Users/falfaro/.ssh/config
    debug1: Applying options for *
    debug1: Reading configuration data /etc/ssh_config
    debug1: Connecting to solana [10.42.242.12] port 22.
    debug1: Connection established.
    debug1: identity file /Users/falfaro/.ssh/id_rsa type -1
    debug1: identity file /Users/falfaro/.ssh/id_dsa type 2
    debug1: Remote protocol version 2.0, remote software version OpenSSH_4.5
    debug1: match: OpenSSH_4.5 pat OpenSSH*
    debug1: Enabling compatibility mode for protocol 2.0
    debug1: Local version string SSH-2.0-OpenSSH_4.5
    debug1: Offering GSSAPI proposal:
     gss-gex-sha1-toWM5Slw5Ew8Mqkay+al2g==,
     gss-group1-sha1-toWM5Slw5Ew8Mqkay+al2g==,
     gss-group14-sha1-toWM5Slw5Ew8Mqkay+al2g==,
     gss-gex-sha1-A/vxljAEU54gt9a48EiANQ==,
     gss-group1-sha1-A/vxljAEU54gt9a48EiANQ==,
     gss-group14-sha1-A/vxljAEU54gt9a48EiANQ==,
     gss-gex-sha1-bontcUwnM6aGfWCP21alxQ==,
     gss-group1-sha1-bontcUwnM6aGfWCP21alxQ==,
     gss-group14-sha1-bontcUwnM6aGfWCP21alxQ==
    debug1: SSH2_MSG_KEXINIT sent
    debug1: SSH2_MSG_KEXINIT received
    debug1: kex: server->client aes128-cbc hmac-md5 none
    debug1: kex: client->server aes128-cbc hmac-md5 none
    debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
    debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
    debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
    debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
    debug1: Host 'solana' is known and matches the RSA host key.
    debug1: Found key in /Users/falfaro/.ssh/known_hosts:8
    debug1: ssh_rsa_verify: signature correct
    debug1: SSH2_MSG_NEWKEYS sent
    debug1: expecting SSH2_MSG_NEWKEYS
    debug1: SSH2_MSG_NEWKEYS received
    debug1: SSH2_MSG_SERVICE_REQUEST sent
    debug1: SSH2_MSG_SERVICE_ACCEPT received
    debug1: Authentications that can continue:
     publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive
    debug1: Next authentication method: gssapi-keyex
    debug1: No valid Key exchange context
    debug1: Next authentication method: gssapi-with-mic
    debug1: Authentication succeeded (gssapi-with-mic).
    debug1: channel 0: new [client-session]
    debug1: Entering interactive session.
    Last login: Thu Dec  6 20:29:59 2007 from foo.lan
    $ hostname
    ssh.lan
    $ exit
    logout
    Connection to solana closed.
    

    If we run klist again, we will see that, in addition to the TGT we saw before, we will see the Kerberos service ticket for the OpenSSH server:

    Kerberos 5 ticket cache: 'API:Initial default ccache'
    Default principal: alice@LAN
    
    Valid Starting     Expires            Service Principal
    12/06/07 18:06:26  12/07/07 04:06:26  krbtgt/LAN@LAN
    	renew until 12/13/07 18:06:26
    12/06/07 18:07:27  12/07/07 04:06:26  host/ssh.lan@LAN
    	renew until 12/13/07 18:06:26
    

    8. Troubleshooting

    The GSSAPI authentication mechanism is very picky about many things, and error codes and messages are usually very cryptic but not very helpful about what the cause of the error is.

    I found that acommon source of authentication problems are entries in /etc/hosts confusing GSSAPi about the host name. For example, entries like this in /etc/hosts:

    192.168.0.1  ssh ssh.lan
    

    can cause SSH to think the host name is ssh instead of the expected FQDN — ssh.lan.The previous entry causes reverse name resolutions for IP 192.168.0.1 to return ssh as the host name, but not ssh.lan. Since the Kerberos keytab is host/ssh.lan but IP 192.168.0.1 is resolved to ssh this may cause authentication attempts to fail because no Kerberos keytab for host/ssh exists in /etc/krb5.keytab. The most common symptom is trying to SSH to localhost, getting a failed authentication and but ticket for the target host. Example:

    $ kinit
    Password for alice@LAN:
    
    $ klist
    Ticket cache: FILE:/tmp/krb5cc_501
    Default principal: alice@LAN
    
    Valid starting     Expires            Service principal
    05/31/09 01:08:21  06/01/09 01:08:20  krbtgt/LAN@LAN
    

    Then,

    $ ssh ssh.lan
    alice@ssh.lan's password:
    

    But no Kerberos ticket for ssh.lan was even requested:

    $ klist
    Ticket cache: FILE:/tmp/krb5cc_501
    Default principal: alice@LAN
    
    Valid starting     Expires            Service principal
    05/31/09 01:08:21  06/01/09 01:08:20  krbtgt/LAN@LAN
    

    One possible solution consists of removing the matching entry from /etc/hosts, provided that the existing DNS name server can properly resolve the IP address of the server to the correct FQDN. If this is not possible, another solution is making sure the FQDN name is listed before the non-FQDN name in the corresponding line in /etc/hosts.

    8. References

    Some additional and very useful references:

    • Kerberos 5 setup for NFSv4.

      Describes common pitfalls, like using a non-FQDN host name in /etc/hosts or not using clock synchronization.

    Advertisements

    4 thoughts on “Kerberizing Leopard's Remote Login (built-in SSH) service

    1. i did exactly the same as described above.
      but still on doing ssh after kinit, it is asking the password.

      and it is showing something like:

      Next authentication method: gssapi-keyex
      debug1: No valid Key exchange context
      debug1: Next authentication method: gssapi-with-mic
      debug1: packet not sent

      why so?

    2. As an employee of A+ Federal Credit Union, I would like to clarify a couple of things regarding our 5% CD:
      1. First, we have 11 branch locations in the Austin, TX area(not just San Marcos, TX) and an online branch (you can open the CD online)
      2. The only “other account” that someone must open to get the 5% CD is a Savings Account with a balance of $10.
      3. If you have children, for example, you can open an account for them and also open a 5% CD for each of them.

    3. Good post. I study something tougher on totally different blogs everyday. It should all the time be stimulating to learn content material from different writers and practice a little bit something from their store. I’d desire to make use of some with the content material on my blog whether you don’t mind. Natually I’ll give you a link in your internet blog. Thanks for sharing.

    Leave a Reply

    Fill in your details below or click an icon to log in:

    WordPress.com Logo

    You are commenting using your WordPress.com account. Log Out / Change )

    Twitter picture

    You are commenting using your Twitter account. Log Out / Change )

    Facebook photo

    You are commenting using your Facebook account. Log Out / Change )

    Google+ photo

    You are commenting using your Google+ account. Log Out / Change )

    Connecting to %s