Custom Query (1145 matches)

Reported by geofft, 11 years ago.

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.

Reported by jdreed, 11 years ago.

dasource, gen-packages, check-unbuilt-packages, and ood-packages all assume svn.

Reported by kaduk, 11 years ago.

debathena-moira-clients at svn r4114 is broken, as seen on athena.dialup and reported in help.mit.edu #2490692. It looks like the (argc < U_END) check in get_shell() is failing, potentially due to mangling of argc done in moira r4114 (which was needed to adjust for the mismatch where affiliation fields are returned by get but not exposed to update. (This is still speculation.)