What’s different in a Kerberos environment? (Frequently Asked Questions)

SSH keys will not work as expected when remotely logging in

We recommend against using them for remote access to our lab and desktop Linux systems. (Note that SSH keys will continue to work for data center hosted remote access Linux systems that are not using Kerberos for file access authorization.) See:

https://cat.pdx.edu/platforms/linux/user-environment/kerberos/ssh/#ssh-keys

You are unable to log to any Kerberos controlled machine

If you are able to successfully log into a non-Kerberos controlled Linux host (such as a remote-access-only data center system) but you are NOT able to login to a Kerberos controlled Linux workstation, it is possible that your password has not been properly registered with Kerberos. To fix this, you can first try logging into one of the remote access Linux systems that is not Kerberos controlled. If you have not been registered with Kerberos previously, doing this will sync your password with the service and you will be able to log into Kerberos controlled systems shortly thereafter.

If the above method doesn’t work, it is possible that Kerberos has an issue with the credentials it has registered for you. To fix this, please reset your MCECS password via the Intranet.

http://intranet.cecs.pdx.edu/password

This password change will also be propagated to Kerberos.

Running LRPs or Multiple Jobs across lab machines will require some setup

If you intend to remotely launch a series of processes on various lab systems (especially LRPs – Long Running Processes), it is best to dispatch your work from a remote bastion that is not Kerberos controlled (such as one of the remote login systems). You will need to set up your initial Kerberos ticket:

https://cat.pdx.edu/platforms/linux/user-environment/kerberos/init/

and ensure that a ticket is propagated to the Kerberos controlled machines you SSH into:

https://cat.pdx.edu/platforms/linux/user-environment/kerberos/ssh/#no-kerberos

And if the processes are intended to run beyond the ticket expiry time, you will need to ensure that you have set up the appropriate mechanism to auto-renew your tickets:

https://cat.pdx.edu/platforms/linux/user-environment/kerberos/renew/

Note that you will not be able to renew a ticket beyond its renewal time limit.

Cron Jobs started on Kerberos controlled hosts will not be able to access your files

Since cron jobs will not be starting with a valid ticket, your home directory and stashes will not be available. We have some recommendations on how to deal with that here:

https://cat.pdx.edu/platforms/linux/user-environment/kerberos/cron/

Managing long term desktop logins on a Kerberos controlled workstation

If you tend to leave yourself logged into your Kerberos controlled workstation for extended periods of time, you may need to ensure that your Kerberos ticket stays active (or a new ticket generated periodically). This is so that your home directory and other NFS mounted file systems you use stay authenticated in case some element in your desktop needs to access them.

If you are a daily desktop user, most screen unlock methods that require a password will re-initialize a new Kerberos ticket. However, if you are leaving yourself logged in for a few days without logging in (like the weekend), you may need to set up an automated krenew process via a systemd user unit to keep it renewed until you unlock your screen.