[2301] in athena10
Re: [Debathena] #205: ssh changes behavior from Athena 9,
daemon@ATHENA.MIT.EDU (Debathena Trac)
Wed Apr 15 20:22:20 2009
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
From: "Debathena Trac" <debathena@MIT.EDU>
Cc: debathena@mit.edu
To: jmorzins@mit.edu, andersk@mit.edu, jdreed@mit.edu
Date: Thu, 16 Apr 2009 00:22:00 -0000
Reply-To:
Message-ID: <054.f39b97fabe498d807d9ce0cabbf8a977@mit.edu>
In-Reply-To: <045.dc406a80e7544701121648e9f5b55df5@mit.edu>
Content-Transfer-Encoding: 8bit
#205: ssh changes behavior from Athena 9, does not delegate tickets by default-------------------------+--------------------------------------------------
Reporter: jmorzins | Owner:
Type: defect | Status: new
Priority: major | Component: --
Keywords: ssh kerberos |
-------------------------+--------------------------------------------------
Comment(by jdreed):
Replying to [comment:1 andersk]:
> • Athena 9 customizes the SSH client to force GSSAPIDelegateCredentials
on. This option causes `ssh` to delegate your Kerberos tickets to any
remote machine, rather than just using them to authenticate. Debathena
does not, so by default it only uses Kerberos to authenticate, unless you
specify `ssh -K`.
Kerberos Extras does this for you on Mac OS X too. I understand why it
could be considered dangerous, but I would like to keep the option of
enabling this for -workstation and -cluster on the table if we get enough
complaints from users. Should we go that route, users who take their
security seriously enough can always have a ~/.ssh/config that overrides
the system defaults.
> • SIPB runs kerberized SSH services, like scripts.mit.edu and the
xvm.mit.edu console server, that explicitly request you to _not_ trust
them with delegated credentials. Especially on scripts.mit.edu, where
unmaintained PHP applications are compromised by script kiddies on a
regular basis, it is important for the server’s accounts to be held at a
lower privilege level than even an average Athena account.
Can't these services be configured to reject delegated credentials, rather
than using it as a rationale for a widespread user behavior change?
> • Many common actions (e.g. logging into linerva to attach a screen with
your Zephyr session) do not require delegation, and for some people it is
even useful to be able to perform these actions using alternate
authentication mechanisms like SSH public keys.
I don't thing these are common actions across the entire user Athena base,
rather I think they're common for Linerva users, which is to some degree a
self-selecting group. Additionally, if your homedir is not system:anyuser
list, you end up in the root directory, which seems like a terrible idea.
Refusing conections that don't delegrate credentials was a deliberate
choice, because it's extremely confusing, and results in a flurry of calls
from users saying "Help, it says permission denied when I try to access my
files."
> • The current Debathena behavior is consistent with the Debian, Ubuntu,
and upstream SSH defaults (which I expect were chosen carefully for much
the same reasons as above).
It's also consistent with the default OS X behavior. However, as noted
above, the decision was made to change that. We should be aware of what
factors went into that decision and why rather than simply dismissing it
as a poor security choice. We should probably solicit input from
krbdev/macdev/whoever.
> There are, in addition, some code changes we could make to nudge users
in the right direction. For example, we could configure dialups to print
a warning when you log in to an Athena account with Kerberos without
delegating credentials, rather than silently rejecting or silently
accepting the login.
If we decide to stick with the current configuration, I think we
definitely need to do this, ideally for debathena-login and higher. The
warning should also, as succinctly as possible, inform users of the
consequences of this (ie: no dotfiles, no homedir access, no running
locker software, no zephyr, etc). Perhaps the right thing to do is to
say "Warning: you have no Kerberos tickets or AFS tokens. For more
information, see http://whatever"
We should also talk to ops about the possibility of enabling this on the
existing dialups. Given that the dialups will be Athena 9 for quite a
while, if enabling this is not possible, I'd really like to configure
-cluster and -workstation to at least delegate credentials to the Athena
dialups. If those are compromised, we're pretty doomed anyway, so I
think it's reasonable to trust them.
-- Ticket URL: <http://debathena.mit.edu/trac/ticket/205#comment:3>Debathena <http://debathena.mit.edu/>MIT Debathena Project
