[2299] in athena10
Re: [Debathena] #205: ssh changes behavior, requires passwords
daemon@ATHENA.MIT.EDU (Debathena Trac)
Wed Apr 15 19:54:27 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
Date: Wed, 15 Apr 2009 23:53:56 -0000
Reply-To:
Message-ID: <054.02c290175891568f0256517337250e27@mit.edu>
In-Reply-To: <045.dc406a80e7544701121648e9f5b55df5@mit.edu>
Content-Transfer-Encoding: 8bit
#205: ssh changes behavior, requires passwords-------------------------+--------------------------------------------------
Reporter: jmorzins | Owner:
Type: defect | Status: new
Priority: major | Component: --
Keywords: ssh kerberos |
-------------------------+--------------------------------------------------
Comment(by andersk):
There are two things going on here:
• 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`.
• Athena 9 customizes the SSH server to reject Kerberos authentication
attempts that do not include such delegations. Debathena does not, so you
can successfully log in with only authentication (but you won’t have
tickets or tokens).
Both of these choices were absolutely deliberate.
In order to delegate your Kerberos tickets from a Debathena client to a
remote server that you trust (as is necessary for an Athena 9 server to
log in at all, and for a Debathena server to have tickets and tokens), you
just need to use `ssh -K some-server` instead of `ssh some-server`. If
you don’t want to type the `-K` every time, you can configure your
~/.ssh/config to trust a particular server by default:
{{{
Host some-server
GSSAPIDelegateCredentials yes
}}}
or even to trust all machines by default, if you really want that:
{{{
Host *
GSSAPIDelegateCredentials yes
}}}
Changing these default on a system-wide basis, for any or all classes of
Debathena systems, would be a mistake for several reasons.
• Kerberos is increasingly used to authenticate sysadmins to their
servers, without necessarily being used remotely once logged in (since the
servers have local accounts rather than using Athena accounts). Debathena
and XVM make this very easy to set up. The fact that those machines trust
your Kerberos principal for authentication should not imply any kind of
trust in the reverse direction. An attacker or another administrator on
one of your servers should not be able to compromise your Athena account,
and with that, compromise every other server you run as well, etc.
• In particular, root instances especially should _never_ be delegated to
remote servers, if they are to be considered secure.
• 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.
• 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.
• 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).
The Debathena behavior is a change from Athena 9, and definitely needs to
be documented. (I thought we had this on the Debathena website already,
but I only see documentation on the [http://web.mit.edu/linerva/www
/#ticket-forwarding Linerva website] and a passing reference on the
[http://debathena.mit.edu/customizing customization page].)
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. So far, Debathena and linerva have not received a
great number of support requests about this behavior (a few, but not too
many, and they’re easy to deal with), so we have not found it necessary.
-- Ticket URL: <http://debathena.mit.edu/~debathena/trac/trac.fcgi/ticket/205#comment:1>Debathena <http://debathena.mit.edu/>MIT Debathena Project
