Access Keys:
Skip to content (Access Key - 0)

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.

IS&T Contributions

Documentation and information provided by IS&T staff members


Last Modified:

January 28, 2014

Get Help

Request help
from the Help Desk
Report a security incident
to the Security Team
Labels:
debathena debathena Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
Feedback
This product/service is:
Easy to use
Average
Difficult to use

This article is:
Helpful
Inaccurate
Obsolete
  1. Feb 16, 2010

    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.

  2. Feb 18, 2010

    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

  3. Feb 19, 2010

    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.

    1. May 11, 2010

      Mail olc@mit.edu; got back:

      That is a bug, and you can report it to bug-dialup@mit.edu

      FYI

  4. Feb 22, 2010

    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.

    1. Feb 23, 2010

      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.

      • On one hand, the institute-supplied SecureCRT isn't initially set up for kerberized logins. You enter your password during login, and get tickets with that password.
      • On another hand, if you enable kerberized logins[*], SecureCRT will forward your tickets with full delegation, the same as the "ssh -K" command that the article describes for Mac and Linux.
        [* 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.]
      • On the gripping hand, there could be another factor at play. There could be a bug with the athena.dialup.mit.edu pool of servers, which could occasionally login people without tickets even if they've done everything else correctly.

      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.

Adaptavist Theme Builder (4.2.3) Powered by Atlassian Confluence 3.5.13, the Enterprise Wiki