Skip Navigation
York U: Redefine the PossibleHOME | Current Students | Faculty & Staff | Research | International
Search »FacultiesLibrariesCampus MapsYork U OrganizationDirectorySite Index
Future Students, Alumni & Visitors
Kerberos for EECS Linux Systems

In order to enhance system security, the tech team has implemented Kerberos across tech supported Linux systems. Our Windows systems already use Kerberos.

The Kerberos protocol uses strong cryptography to allow a client and server to prove their identity to each other over the network.

Kerberos is an authentication protocol that works using tickets. When you login to an EECS Linux system, you will be automatically issued a Kerberos ticket. This ticket is used to gain access to resources such as your home directory, software, or other systems.

How does this affect me?

Kerberos tickets have a 10 hour lifetime, and can be renewed for up to 7 days without needing to re-enter a password. When your Kerberos ticket expires, you will temporarily lose access to the filesystem path /eecs, which includes your home directory, software, and more.

You will not be affected by this change if your usage falls into one of the following categories:

1) Login sessions to indigo/indigo1/navy (research) or red/red1/crimson (education) are not affected by this change.

2) Local logins to office or lab workstations, or logins via remotelab are not affected by this change.

3) Login sessions less than 10 hours in duration will not be affected by this change.

You will be affected by this change if your usage falls into one of the following categories:

1) If you SSH to any tech-managed systems other than indigo/indigo1/navy (research), or red/red1/crimson (education), you will be affected by this change.

2) If your login sessions are typically longer than 10 hours in duration where usage does not fall within the cases unaffected by the change above, you will be affected by this change.

3) If you run unattended jobs that will run for more than 10 hours, you will be affected by this change.

If your system use falls into these categories, you will need to renew your Kerberos ticket either manually, or automatically. Please continue to read this document for additional details.

How can I view my Kerberos ticket?

In order to view your Kerberos Tickets, use the “klist” command from a “Terminal” or SSH session:

% klist
Ticket cache: FILE:/tmp/krb5cc_9999
Default principal: bob@AD.EECS.YORKU.CA

Valid starting       Expires              Service principal
12/16/2020 09:52:21  12/16/2020 19:52:20  krbtgt/AD.EECS.YORKU.CA@AD.EECS.YORKU.CA
	renew until 12/23/2020 09:52:21

Here, we see that user “bob” has a Kerberos ticket created on December 16, 2020 at 9:52:21 AM when he logged in to an EECS Linux system. That ticket will expire in 10 hours, and is renewable for up to 7 days.

How do I renew my Kerberos ticket?

Every time you login to a system, you get a new Kerberos ticket that will expire in 10 hours, and can be renewed up to 7 days.

Before the ticket 10 hour expiry, run the “kinit -R” command which will renew your ticket for another 10 hours. You will not be required to re-enter your password.

After 7 days, or, if you do not renew your ticket before the 10 hour expiry, your ticket is no longer renewable and you need a new one!

How do I get a new Kerberos ticket?

You can get a new Kerberos ticket at any time. Simply run the “kinit” command, enter your password interactively when prompted, and you'll get a new Kerberos ticket that will be valid for 10 hours with a new 7 day expiry. Your ticket doesn't even need to expire before it can be renewed. For example:

% kinit
Password for bob@AD.EECS.YORKU.CA: 
% klist
Ticket cache: FILE:/tmp/krb5cc_9999
Default principal: bob@AD.EECS.YORKU.CA

Valid starting       Expires              Service principal
12/16/2020 10:13:25  12/16/2020 20:13:25  krbtgt/AD.EECS.YORKU.CA@AD.EECS.YORKU.CA
	renew until 12/23/2020 10:13:23

How do I destroy my Kerberos ticket?

You can manually destroy your ticket at any time using the “kdestroy” command. For example:

% kdestroy
% klist
klist: No credentials cache found (filename: /tmp/krb5cc_9999)

Although the ticket remains cached in memory for some time, Bob will eventually lose access to his home directory. However, the next time Bob logs in, he will get a new ticket, and access will resume.

Processes That Run for Up To 7 Days

For processes that will run for up to 7 days where it would be impractical to manually renew the Kerberos ticket every 10 hours, follow this procedure:

Run your job using krenew:

krenew -- <command>

This will run <command> in the foreground. It will renew your ticket before the 10 hour expiry, for up to 7 days. After 7 days, your Kerberos ticket will expire, and your process will lose access to /eecs.

krenew can also be used to run the command in the background like this:

krenew -b -- <full path to command>

Finally, if instead of running a process, you want the Kerberos ticket of your SSH login session to automatically remain valid for up to 7 days, just run “krenew” like this:

krenew -K 60 -b

krenew will run in the background, automatically renewing your Kerberos ticket for your login session. That session will remain valid for up to 7 days. As always, use “klist” to view your Kerberos tickets at any time.

Processes That Run for More Than 7 Days

For processes that will run for more than 7 days, where it is obviously impractical to constantly renew your Kerberos ticket every 10 hours, follow this procedure:

First, you will create a custom keytab file using the ktutil command, replacing <user> with your username:

% ktutil
ktutil: addent -password -p <user> -k 1 -e aes256-cts
Password for <user>@AD.EECS.YORKU.CA: [enter your password]
ktutil: wkt /eecs/home/<user>/<user>.keytab
ktutil: quit

The keytab file will be written to a file called <user>.keytab in your home directory. You can name the file whatever you like. The permission on the file will be 600. That is, the file will be readable by you, and only you. Please don't change the permission on this file. If someone gets a hold of this file, they will be able to access your files, so please protect this file, and delete it, if possible, after your long running process completes.

Test that the keytab file can be used to authenticate as you. First, run “kdestroy” to destroy your current Kerberos ticket:

% kdestroy

You can optionally test your keytab file by passing it to kinit like this:

% kinit <user> -k -t /eecs/home/<user>/<user>.keytab

Note that you will not be asked to enter your password because the keytab file includes what is required for kinit to initialize your Kerberos ticket.

If you see the following error:

kinit: Pre-authentication failed: No key table entry found for <user>@AD.EECS.YORKU.CA while getting initial credentials

… then your password is too old. Please use the “passwd” command to change your system password, then re-issue the ktutil command above, and it will work now.

You should be able to list your new Kerberos ticket using the “klist” command. You will see that it is valid for 10 hours with a 7 day expiry.

Now, you can run your job using k5start:

k5start -f <full path to keytab file> <user>  -- <full path to command>

This will run the command in the foreground. Your command will continue to run with a ticket that will be renewed indefinately using your keytab file. Stop the k5start process, and your ticket will no longer be renewed.

k5start can also be used to run your command in the background like this:

k5start -f <full path to keytab file> <user> -b -- <full path to command>

Finally, if instead of running a process, you want the Kerberos ticket of your SSH login session to remain valid indefinately, just run “k5start” like this:

k5start -f <full path to keytab file> -K 60 <user> -b

Now, k5start will use your keytab file to renew your Kerberos ticket for this session indefinately.

Please note that if you change your password at any point in time, you will also need to regenerate your keytab file.

Additional Information

If you're interested in learning more about Kerberos, you can read this or watch this video.

As always, be sure to email tech with any questions that you might have.

Last modified:
2021/07/16 13:01