Ticket #1386 (closed enhancement: fixed)

Opened 8 years ago

Last modified 7 years ago

Consider some special-case ssh config for athena.dialup

Reported by: geofft Owned by:
Priority: low Milestone: The Distant Future
Component: -- Keywords:
Cc: Fixed in version: 1.7
Upstream bug:

Description

Given the concerns in #1384, delegating Kerberos credentials is currently somewhat unsafe -- an attacker who can intercept DNS requests can redirect you to their own server pretending to be athena.dialup. Meanwhile, since athena.dialup doesn't accept non-delegated Kerberos login, users will probably end up in the habit of running ssh -K to get there.

Alex Dehnert pointed out that the security model of SSH's known_hosts file does not involve DNS canonicalization (all the dialups share a single SSH host key), and proposed disabling GSSAPIKeyExchange as a mitigation for #1384 so that, if an attacker tries to spoof athena.dialup, host key exchange will fail. I don't think disabling it globally is quite warranted, but I could see an argument for disabling it just for athena.dialup, given the delegation risk (and maybe Linerva too, while we're at it).

Of course, that would now make users see a host key prompt for athena.dialup. We could skip that by shipping an /etc/ssh/ssh_known_hosts file with an entry for athena.dialup.mit.edu, so the initial trust prompt is skipped and there's a fully trusted path via the Debathena package. Then we could add something like

Host athena.dialup.mit.edu athena.dialup
    HostName athena.dialup.mit.edu
    GSSAPIKeyExchange no

to /etc/ssh/ssh_config, and the UX would remain the same. (We could also then safely turn on GSSAPIDelegateCredentials yes, in the unlikely event we decided to rethink #205).

There would be a slight amount of update pain if athena.dialup ever rekeys, but, I'm sure that will be a massive pain anyway (to update users' .ssh/known_hosts files everywhere) so I think that's okay.

There's not a particular need to do this for any of the individual athena.dialup servers, I think, and they'd be annoying to manage because the list of servers changes. But we could, if we wanted.

Change History

comment:1 Changed 8 years ago by geofft

There's some discussion on zephyr about turning off GSSAPIKeyExchange globally as a mitigation for #1384, and shipping a global known_hosts file for athena.dialup, Linerva, and maybe scripts and some others that we think are high-value targets, are commonly used, and will have stable host keys, to avoid the TOFU prompt (both for security and UX reasons). I am mildly against turning it off globally having turned it on, and kind of wish we'd never turned it on, since now people will get host key prompts to things that we're not shipping keys for. But I can see the argument -- if you're sshing to a server that has nothing to do with Athena, we've now introduced a vulnerability via DNS that wouldn't exist in the upstream configuration.

Also, Anders points out that GlobalKnownHostsFile takes multiple options, so we can add /etc/ssh/ssh_known_hosts.debathena to that list so that we don't have to worry about colliding with an existing system-wide known hosts file on anyone's system.

comment:2 Changed 8 years ago by geofft

Note that I personally am incredibly unlikely to drive decisions about Athena's security model any more, and am mostly interested in this because I'm interested in Kerberos in general (so I'm willing to do exploratory work in the Athena environment but not Debathena-specific things). If anyone feels strongly about GSSAPIKeyExchange, they should make some actual decision here and write a patch.

comment:3 Changed 7 years ago by andersk

  • Status changed from new to development
  • Fixed in version set to 1.7

comment:4 Changed 7 years ago by andersk

  • Status changed from development to proposed

comment:5 Changed 7 years ago by jdreed

1.8 is now in -proposed.

comment:6 Changed 7 years ago by jdreed

  • Status changed from proposed to closed
  • Resolution set to fixed
Note: See TracTickets for help on using tickets.