Ticket #1216 (closed defect: fixed)

Opened 9 years ago

Last modified 7 years ago

Opt-in support for ssh -k / public keys on athena.dialup

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

Description

It would be kind of nifty if the athena.dialup patch let you opt in somehow (e.g. via creation of a flag file .ssh/i-know-what-i-am-doing) to login methods that don't end up with valid Kerberos tickets. Currently those are disabled to force you to type a password, so that new users don't get confused.

I currently use public key support a lot (because I log in from an iDevice where typing in a password is a pain, and there are no Kerberized SSH clients as far as I know) to reattach to a ticketed screen session, so would be sad to see this go away.

Change History

comment:1 Changed 9 years ago by adehnert

  • Keywords transition added

comment:2 Changed 8 years ago by adehnert

See also #500 for getting the non-keys patch upstream.

comment:3 Changed 8 years ago by adehnert

It occurs to me that opting in by adding a flag file is supportable without any code changes. We can use a distinctively-named authorized keys file (e.g., .ssh/dialup_authorized_keys), and then people opt-in to ssh key login by dropping their key in our custom file (or symlinking it to .ssh/authorized_keys if they prefer). It looks like publickey is currently disabled, so I think enabling it and setting "AuthorizedKeysFile .ssh/dialup_authorized_keys" or so would work.

As a possible bonus, this means you can support a different key on the dialups than on other machines if you like (though I'm not totally sure when this would be handy).

comment:4 follow-up: ↓ 11 Changed 8 years ago by jweiss

This is now available for testing on test.dialup.mit.edu. The custom path is Public/.ssh/athena_dialup_authorized_keys Any documentation that mentions this should be very clear that you won't get Kerberos tickets, and without them many things will break.

comment:5 Changed 8 years ago by jweiss

I should also note that I don't see a lot of value in 'ssh -k' working to the dialups (without forcing you to type a password). I'm planning not to support that at this time. Please shout if you think I'm missing something.

comment:6 follow-up: ↓ 7 Changed 8 years ago by quentin

The value for "ssh -k" is that, with the default Debathena configuration, you can log in to a workstation and do

ssh $dialup -t screen -dR

to reattach to your screen, no delegation necessary.

(or from your personal machine with Kerberos, etc.)

comment:7 in reply to: ↑ 6 Changed 8 years ago by jweiss

But if you're using Kerberos to auth, and you presumably already have tickets for the screen session, what do you care if you delegate a new set? (and if I wasn't clear, and you're using ssh publickey to auth that's fine (even if you have tix and specif 'ssh -k' or if you don't have tix) since it goes thru a different code path in sshd (currently on test.dialup.mit.edu but should hit the production ones in a week or two).

comment:8 Changed 8 years ago by quentin

If I had to guess, it's somewhere between "I don't want to have to type ssh -K every time I connect to the dialups", and "my pointy hat is this long and I want to use a different principal from the one in the screen" (e.g. .k5login usage). Personally, for me, it's the former. (And I think Debathena doesn't want to encourage people to forward tickets when they don't have to, since they previously removed delegation-by-default.)

comment:9 Changed 8 years ago by kchen

One other use case is for mosh, where I'm not sure offhand how to do ssh -K, although I probably could find out somehow. (Then again, with mosh, I have to connect infrequently enough that it may not matter.)

comment:10 Changed 8 years ago by geofft

Yeah, I think this is more of a UX issue than a security issue, if I'm understanding correctly.

Debathena disables ticket delegation by default, since it's a security risk when you're SSHing to an arbitrary server. Using upstream ssh to connect somewhere does not imply extending any trust to that server, and changing that seems like a poor idea.

I do concur with Jonathon that in the specific case of athena.dialup and moreover in the specific case of a screen session on athena.dialup, there's probably no security boundary, since we're talking about the default Debathena configuration and you probably have valid tickets on athena.dialup if you expect your screen session to work. (IMO using a .k5login on athena.dialup should basically be considered unsupported, if it even currently happens to work.)

But that doesn't hugely help us from a UX perspective, since you need to type in ssh -K, which is anywhere from annoying (as Quentin points out) to really annoying (as Kevin points out, for mosh).

We have talked about modifying our configuration to allow delegating tickets by default to athena.dialup and nowhere else. I'm not very sure if I like that idea, but at least at the moment, that's a very bad idea because both SSH and the Kerberos libraries trust DNS for canonicalization -- and the setup of athena.dialup's load balancer currently heavily requires the use of DNS for this purpose. If we turned off DNS canonicalization, that would make this a better idea, although I'm still not sure if I'd like it. I'll open a ticket about that, because it's probably worth doing anyway.

Kevin: With a semi-recent version of mosh, you can run mosh --ssh="ssh -K" athena.dialup.mit.edu.

comment:11 in reply to: ↑ 4 Changed 8 years ago by jweiss

Replying to jweiss:

This is now available for testing on test.dialup.mit.edu. The custom path is Public/.ssh/athena_dialup_authorized_keys Any documentation that mentions this should be very clear that you won't get Kerberos tickets, and without them many things will break.

This is now deployed in production, I'm still contemplating whether it's worth enabling ssh -k under explicit opt-in, but I'm leaning toward "no".

comment:12 Changed 7 years ago by adehnert

  • Status changed from new to closed
  • Resolution set to fixed

Marking as resolved. Thanks for doing this.

Note: See TracTickets for help on using tickets.