Freeblog689

Because OpenSSH supports Kerberos-5 only for SSH-1. This is not ideal, as SSH-1 is deprecated for its known security weaknesses, but SSH-2 has no standard support for Kerberos yet. However, there is a proposal to add it via GSSAPI (Generic Security Services Application Programming Interface, RFC 1964).

• Windows Openssh Kerberos
• Gssapi Authentication Failed

• SSO not working with OpenSSH - I have not been able to get GSSAPIAuthentication to work with Kerberos. Everytime I attempted to login, I kept getting prompted for the password.
• OpenSSH and Kerberos Version 5 support Kerberos is an authentication mechanism that provides a secure means of authentication for network users. It prevents transmission of clear text passwords over the network by encrypting authentication.

This article explains a little bit about the Kerberos protocol and how it can be used in Ubuntu. It's not a thorough manual, use more authoritative sources to get more accurate information and update if you see obvious mistakes.

Regular authentication, directory and Kerberos

In regular, or disjoint services, a user can get access to the service by providing his user+password to the service, which verifies it against its own store. Whenever you change the password there, it is only changed for that particular service.

As this causes some issues, i.e. the user needs to maintain many different passwords on all the services, a central directory protocol (LDAP) was standardized, so that the service can connect to a directory to verify the user credentials for the service. Although the user still needs to authenticate separately to each service, his password is kept consistent, as it is enough to just update the directory.

There is one other problem left with this scheme: if any of the services gets compromised, the user password can be used to acquire access to any other service. Kerberos was designed to solve this particular issue.

Kerberos tickets

Kerberos is about tickets: you have a Kerberos ticket for everything: for the master Kerberos server, for any service you authenticate against, for getting service tickets and for the services themselves.

From the client perspecive, it looks like this: you authenticate against the master Kerberos server and acquire a TGT (ticket granting ticket). When you want to authenticate to a service (say https://webserver.example.com), you use your TGT to acquire a ticket for the service you connect to. The service needs to have a previously-acquired Principal ticket and it verifies the ticket from the request with its principal ticket.

This provides a neat single sign-on mechanism - you do not need to enter your password for every service, as there is no password required, just the ticket which is acquired based on the initial log in.

Kerberos in Microsoft Directory Services

Microsoft Directory Services, also known as the Active Directory, provide both LDAP and Kerberos protocol implementations and they are on by default. The Domain Controllers hold the Kerberos Key Distribution Centre (KDC) role and can generate both the SPN (Service Principal Name) tickets, the TGT tickets and the service client tickets.

All the Windows machines have a machine account in Active Directory. In technical terms this machine account is very similar to a user account - it has its name and password, it can have its TGT ticket and a service ticket. You can also assign a SPN ticket to an account (machine or account). A subtle difference is that in LDAP the machine name has a dollar sign added to it in its samaccountname attribute, whereas a regular user account does not. Also the LDAP attributes may be different between a machine account and a user account.

Kerberos from a Ubuntu client perspective

For the correct configuration of a Ubuntu client to work in a Kerberos environment, please follow either sssd guide or LDAP+Kerberos guide. Either of those authentication methods should provide you with a valid TGT upon login. You can verify this by issuing the 'klist' command. The excerpt below was done after logging in:

When you connect using Kerberos to any Kerberized service, klist should also list the ticket for that particular service. The excerpt below shows a klist output upon authenticationg to a Kerberized webserver:

What you can do with a machine client ticket

If a Ubuntu machine has a respective AD machine account, it can use it for a couple of interesting cases.

First of all, the machine$ account behaves similarly to a user account. It is possible to login and act in the name of the machine account. So, it is possible to log into the AD's LDAP with the account to get the list of users. It is possible to grant access to Windows shares to machine accounts and access it from a script which uses the machine account.

Machine account has a machine password which can expire, so it is a good habit to periodically verify that the machine account is valid and to change the machine account password. This also triggers an update to the account's tickets.

In some (most?) AD-based DNS implementations it is also possible to use nsupdate to update DNS entries (A and PTR) and correct them if they are no longer valid, using the Kerberos machine account client ticket.

How to acquire the machine ticket

To acquire the aforementioned machine client ticket, you need to acquire the TGT ticket of the user that can join the machine to the domain (an admin account in most cases, but you can grant joining rights for the particular machine to a particular user) and use msktutil (http://code.google.com/p/msktutil/) to get the SPN ticket for the machine:

This is how you can verify that your machine has a valid Kerberos client ticket. Note 'sudo su -', not 'sudo -s', as we need the root's environment, including its Kerberos ticket cache.

Kerberized SSH

Once msktutil is run, the machine gets an SPN ticket for the host service. This service is used by the SSH service. Installing ssh-krb5 configures SSH daemon with GSSAPI enabled. This allows you to ssh to your Ubuntu machine without providing your password (of course, to your account on that machine). You don't even need SSH keys for that.

To verify your Kerberos-based SSH server works

1. Check your Kerberos SPN cache:

• Note that you can see the 'host/' principal here. CASE MATTERS! The ssh service requires a lowercase 'host' service. If it's uppercase, it requires correction.

1. Check your /etc/ssh/sshd_config. It should contain the line:

1. Check that you can connect to the machine without entering your password. You may need to specify the whole fqdn for connection. Below excerpt is from verbose mode:

1. After a kerberos connection you should get a service ticket on the client machine:

Kerberized HTTP

If you wanted to provide single-sign-on to your webserver running on a Ubuntu machine, here's a rough how-to:

1. Verify you have a valid machine client ticket:

1. Acquire the HTTP service ticket from AD. Note CASE MATTERS. It's uppercase HTTP, not lowercase, unlike the 'host' service. Use HTTP even if you plan to use 'https://' (secure http).

1. Verify your service ticket is in place. Look only at the highest KVNO (key version number), as the previous ones are kept in the keytab to maintain previous sessions.

1. Install apache2 and libapache2-mod-auth-kerb packages. Configure the location you want to authenticate users:

• Note that by default, Firefox browser in Ubuntu only trust 'https://' sites for Kerberos authentication, so you need to get a valid SSL certificate and configure https. For debugging you can change the client's about:config setting 'network.negotiate-auth.trusted-uris'.

Testing Kerberized HTTP

Try logging in to the webpage you configured for Kerberos. You should be automatically logged in, and the tickets cache should show your client service ticket:

If the authentication does not work for some reason, check if the Kerberos ticket version is valid and contains the valid crypttypes. You can

I have also noticed that some valid services return kvno higher by 256 than the version in the keytab and this kvno seems to be valid too.

Alternative server name

Now, what if you wanted to have a service accessible not only with machine.example.com, but, also, say, webserver.example.com? It's possible, but not obvious.

Theoretically getting a DNS CNAME record should be enough. When a client tries to connect to webserver.example.com it will find it's a CNAME for machine.example.com and acquire a ticket for machine.example.com. Unfortunately, that does not always work. From my testing, it works from Windows clients and from Ubuntu, if you override the MIT gssapi with Heimdal's gssapi library. The behaviour, however, is not consistent when you use a proxy. It may or may not work.

So, what you need is to have a Kerberos SPN for that webserver.example.com domain name. Unfortunately, msktutil is only allowed to provide you with the fqdn of your machine. You need an AD admin to grant you a service for a different fqdn. Once you acquired a DNS (preferably CNAME) for your service, you need to have your AD domain admin run something like the commands below.

This one adds a kerberos HTTP service ticket for webserver.example.com and www.webserver.example.com to 'machine' machine account.

Once this is done, you need to update your keytable with 'msktutil -u'. Voila.

Web portal served by multiple servers

Active Directory generates an integrated Kerberos keytab for all services belonging to an account. So if you want to provide a service called balanced.example.com and you assign the SPN to machine 'machine1' (with setspn.exe as above), it can ONLY be used with that machine. You CANNOT add the same SPN to a 'machine2' machine account. Setspn.exe will allow that but both machines will be roasted, I mean, Kerberos authentication will no longer work.

In order to provide a Kerberos ticket for the same SPN for both machines, you need to acquire an AD user, most likely a regular user, not a machine account and assign the SPN with setspn.exe to that user and to NO ONE ELSE. You can verify duplicate SPNs on Windows 7+ with setspn.exe -X. Note that most likely you will need to set the user account with a password that does not expire.

The functionality in msktutil is only present in the 0.5 release of msktutil.

Use kinit on one of the machines using the user principals and run msktutil to get the user keytab (sorry, I did not test this command):

Enterprise/Authentication/KerberosServices (last edited 2013-11-07 06:35:36 by ballock)

Answer

Most ssh client configurations (such as those on MacOS X and Ubuntu) do not delegate (forward) Kerberos tickets by default, to avoid inadvertently exposing your Kerberos tickets to a malicious machine. Normally, you must use ssh -K to delegate your tickets on a per-connection basis. For example, instead of typing:

Windows Openssh Kerberos

you would now type:

NOTE for Mac OS X: Kerberos Extras will configure your ssh client to delegate kerberos tickets.

Delegating by default

If you wish to delegate your tickets by default, you can add a line like the following to your ~/.ssh/config file:

That will cause ssh to delegate your credentials when connecting to athena.dialup.mit.edu (but not when connecting to other machines). You can specify multiple hosts like so:

You can even specify wildcards, though we do not recommend you do this:

Gssapi Authentication Failed