Differences

This shows you the differences between two versions of the page.

--- login:kerberos [2021/07/03 11:17] – jas
+++ login:kerberos [2024/01/22 09:25] (current) – jas
@@ Line 5: / Line 5: @@
 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, or other systems.
+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? =====
+===== How does this affect me? =====
-Kerberos tickets have a 10 hour lifetime.  Typically, when they expire, you lose access to your home directory until you get a new ticket.  Most of our users will be **unaffected** by this change for these reasons:
+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.
-) If your login session is less than 10 hours in duration, you won't be affected by this change no matter which system you use.
+You will **not** be affected by this change if your usage falls into one of the following categories:
-) Login sessions to indigo/indigo1/navy (research) or red/red1/crimson (education) are not affected by Kerberos ticket expiry.
+) Login sessions to indigo/indigo1 (research) or red/red1/crimson (education) are not affected by this change.
-) In general, Kerberos tickets can be manually renewed for up to 7 days.  However, on our system, all active Kerberos tickets will be **automatically** renewed for 7 days without any user intervention.  This means that if your login session to any system is less than 7 days in duration, you also won't be affected by this change.
+) Local logins to office or lab workstations, or logins via remotelab are not affected by this change.
-) Every time you login to our system using your password, you get a new Kerberos ticket which is also valid for an additional 7 days.
+) Login sessions less than 10 hours in duration will not be affected by this change.
-Now let's review the cases where users **will** be affected by this change, and possible solutions:
+You **will** be affected by this change if your usage falls into one of the following categories:
-(a) You have login sessions that will last longer than 7 days to systems other than indigo/indigo1/navy (research) or red/red1/crimson (education):
+) If you SSH to any tech-managed systems other than indigo/indigo1 (research), or red/red1/crimson (education), you will be affected by this change.
-If your login session will last longer than 7 days, you will be affected by this change.  Simply run the "kinit" command before your ticket expires.  You will be prompted to enter your password, and you will get a new Kerberos ticket that lasts for 7 days from that point.  If you forget to renew your ticket before it expires, the programs that you're running will lose access to your home directory, but you can still run kinit at that point and regain access.
+) 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.
-(b) You are running an unattended script which will run for more than 7 days:
+) If you run unattended jobs that will run for more than 10 hours, you will be affected by this change.
-If you will be running an unattended script which will run for longer than 7 days, you may be affected by this change.  If your script is running on the compute server "navy", you will not 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.
-Otherwise, run the "kinit" command before your ticket expires in 7 days, and you will get a new ticket that lasts for 7 days.  Your script will continue to run for another 7 days without intervention.  If you forget, and your ticket expires, your unattended script will not be able to access software in /eecs/local, or access your home directory until you type "kinit" and renew your ticket.
+===== How can I view my Kerberos ticket? =====
-Alternatively, you can create a cron job which will renew your ticket automatically.  Please see below for more details on completing this step, or consult with tech.
-(c) You are running cron/at jobs on a system other than indigo/indigo1/navy (research), or red/red1/crimson (education):
-All cron/at jobs run as you.  Without a Kerberos ticket, the cron job will not be able to access /eecs or your home directory unless you keep your Kerberos ticket active.  As long as you login with your password once every 7 days, your cron job will continue to run.
-Alternatively, you can create a cron job which will renew your ticket automatically.  Please see below for more details on completing this step, or consult with tech.
-It is preferable, if possible, to run your at/cron jobs on indigo/indigo1/navy/red/red1/crimson because these systems are not affected by the expiry of your Kerberos ticket.
-===== View Your Kerberos Ticket =====
 In order to view your Kerberos Tickets, use the "klist" command from a "Terminal" or SSH session:
@@ Line 55: / Line 43: @@
 </code>
-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.  Bob can ignore the 10 hour ticket expiry because our system will renew the ticket for him right until the expiry in 7 days.  If Bob's typical login session is less than 7 days, Bob's ticket will not expire during his login session, so there's nothing special he needs to do.
+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.
-===== Destroy Your Kerberos Ticket =====
+===== How do I renew my Kerberos ticket? =====
-Bob can destroy his Kerberos ticket at any time using the "kdestroy" command:
+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.
-<code>
+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.
-% kdestroy
-% klist
-klist: No credentials cache found (filename: /tmp/krb5cc_9999)
-</code>
-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.
+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!
-You don't need to destroy your Kerberos ticket because it will be destroyed automatically.
+===== How do I get a new Kerberos ticket? =====
-===== 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:
-You can get a new Kerberos ticket at any time.  Simply run the command "kinit", enter your password interactively when prompted, and you'll get a new Kerberos ticket that will be valid for 10 hours, and automatically renewed for up to 7 days.  It's really that simple.
 <code>
@@ Line 87: / Line 69: @@
 </code>
-You can run "kinit" any time you wish to generate a new Kerberos ticket that is valid for an additional 7 days.
+===== How do I destroy my Kerberos ticket? =====
-===== Unattended Scripts or At/Cron Jobs =====
+You can manually destroy your ticket at any time using the "kdestroy" command.  For example:
-If you need to run a long-term unattended script or at/cron job for longer than 7 days on a system other than indigo/indigo1/navy/red/red1/crimson, and you won't be logging in to check on it once every 7 days (thereby renewing your Kerberos ticket), you can set up a cron job to automatically renew your Kerberos ticket for you.  To do this, you will create a "keytab" file that you will be able to pass to "kinit" via a cron job which will renew your ticket for 7 days.  The keytab file does not contain your password, but a key that is derived from your password.  Since the key can be passed to kinit in order to authenticate as you, it **must** be kept secure.  Only create a keytab file **if absolutely necessary**, and delete it if you no longer need to run unattended scripts that run unattended for longer than 7 days.
+<code>
+% kdestroy
+% klist
+klist: No credentials cache found (filename: /tmp/krb5cc_9999)
+</code>
+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 =====
-==== Creating a Keytab ====
+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:
-In order to create a custom keytab file, run the ktutil command, replacing <user> with your username:
+First, you will create a custom keytab file using the ktutil command, replacing <user> with your username:
 <code>
@@ Line 105: / Line 115: @@
 </code>
-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!
+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:
@@ Line 113: / Line 123: @@
 </code>
-Now run kinit, passing in the keytab file:
+You can optionally test your keytab file by passing it to kinit like this:
 <code>
-% kinit bob -k -t /eecs/home/bob/bob.keytab
+% kinit <user> -k -t /eecs/home/<user>/<user>.keytab
 </code>
+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:
@@ Line 127: / Line 139: @@
 ... 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.
-==== Renewing Your Kerberos Ticket via Cron ====
+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.
-Once you can successfully pass your newly created keytab file to kinit without error, now you can make it run daily via a cron job.  Run "crontab -e" to open your list of cron jobs in an editor, then add a line like this, replacing <user> with your username:
+Now, you can run your job using k5start:
-<code>
+  k5start -f <full path to keytab file> <user>  -- <full path to command>
-23 * * * kinit <user> -k -t /eecs/home/<user>/<user>.keytab
-</code>
+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.
-Here, kinit runs at 11:00 PM nightly to renew the users Kerberos ticket for 7 days using the keytab file that you setup.  It doesn't really need to run nightly since the ticket has a 7 day expiry, but it doesn't hurt either. Select any time that you like, and be sure that you specify the correct filename for the keytab file.
+Please note that if you change your password at any point in time, you will also need to regenerate your keytab file.
-NOTE: If the system is rebooted, you will have to login manually one time, then the cron job will take care of ensuring your ticket is renewed from that point forward.
+===== Additional Information =====
-Once again, please only use this procedure if absolutely necessary, and delete the keytab file and cron job when you no longer need to run the script anymore.  This helps to improve the security of your account and our system.
 If you're interested in learning more about Kerberos, you can read [[https://phoenixnap.com/blog/kerberos-authentication|this]] or watch [[https://www.youtube.com/watch?v=kp5d8Yv3-0c|this]] video.
 As always, be sure to email tech with any questions that you might have.