Administration
This page
Other pages
Account
Q: Why don't I get Kerberos tickets or AFS tokens when I connect to a Debathena machine via ssh?
- Why do I get "Permission denied" errors when trying to access my home directory after ssh'ing to a Debathena machine?
- Why do I get one of the following errors when trying to login to a Debathena machine via ssh?
- Could not chdir to home directory /mit/joeuser: Permission denied
- /mit/joeuser/.bash_login: Permission denied
- mailquota: Cannot authenticate to PO12.MIT.EDU
- from: Cannot authenticate to PO12.MIT.EDU
Context
- Debathena workstations
- Remote access (ssh)
Answer
ssh on Athena is configured not to send Kerberos tickets to the remote server by default. To log into a trusted Athena server that requires Kerberos tickets, you must either type your Kerberos password, or use ssh -K to send a copy of your local tickets. If you wish to make this your default setting, please see How do I configure SSH to always delegate my Kerberos tickets?
Details:
When you connect to a Debathena machine via ssh, you can be authenticated in one of several ways. The two most common are GSSAPI (Kerberos) or Keyboard Interactive (typing a password). If you have valid Kerberos tickets on the machine you're connecting from, they will be used to authenticate you to the Debathena machine. However, those tickets will not be forwarded to the Debathena machine by default. This means that although you have logged in to the Debathena machine, you won't have access to your home directory.
To change this, you will need to ensure that you delegate (forward) your tickets to the remote machine when you initially connect via ssh, which is done by providing the -K option to ssh.
6 Comments
comments.show.hideFeb 16, 2010
Erik S. Wile
This just happened to me while ssh'ing in to the athena pool using my kerberos password. I waited a while and got a different machine in the pool and this time I had tickets. So it is possible that the user is doing nothing wrong and just got unlucky with a misbehaving debathena server.
Feb 18, 2010
Bayard W Wenzel
It was giving me a hard time, coming in from outside athena, too. This worked to rectify matters:
athena% kinit
<enter your athena password here>
athena% add `whoami`
NB - in place of `whoami` there you could just use your athena login
Feb 19, 2010
Jacob Morzinski
Erik, if the dialups give you trouble in the future even when you're doing everything else right (using kerberos with "ssh -K", or using interactive password login), please report details of the problem to olc@mit.edu. If there is a systematic problem like a misbehaving debathena server, IS&T would like to hear about it to be able to fix it.
Bayard's steps will work fine once people have an Athena prompt, but the goal is that those steps shouldn't be needed. Maybe there are still bugs in the new system. Report the bugs - if they don't get reported, they might not get fixed.
May 11, 2010
Bayard W Wenzel
Mail olc@mit.edu; got back:
That is a bug, and you can report it to bug-dialup@mit.edu
FYI
Feb 22, 2010
Gary L Dryfoos
Someone using the Institute-supplied SecureCRT might wonder how they can use these helpful instructions.
"At what point in the process, or where in all the menu options, would they have the opportunity to type in that 'ssh -K'?" is what they might be asking themselves.
Feb 23, 2010
Jacob Morzinski
Gary: SecureCRT shouldn't exhibit the specific problem described on this page, the problem of kerberized login working but leaving a person with no tickets in the remote shell after login.
[* To enable kerberized logins in SecureCRT, go to File->Connect, select a session, get Properties, go to the "SSH2" category, examine the "Authentication" box and use the arrow button to move "GSSAPI" to the top of the list.]
If you're doing everything else correctly but you find that your login to the dialups doesn't have tickets, please report the issue. Reports will help IS&T learn whether there is a problem, and whether it is common or rare.