Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
(Nearly) full tickless operation in 3.10
E.g. If you use with kerberos, you get the effect that:
- User has to do a password auth every now and then, as determined by the
administrator (kerberos ticket lifetime)
- In between that time, users get to use their SSH key auth as they wish
Though, probably much better if someone would write a "require non-key auth
periodically" patch for OpenSSH.
SSH: passwords or keys?
Posted Jan 14, 2010 17:17 UTC (Thu) by drag (subscriber, #31333)
Kerberos all the way. That is really the only way to do it and it's sad
that it's still a PITA to get something that should be dead simple
There is a reason why the OpenSSH folks refuse to implement PKI, which is
really what you want to do if your into key management. There are just lots
of problems to a approach like that. Kerberos is just much better.
If you want to do things securely without kerberos then a option is to do a
combination of passwords with a one time password. There are numerous
little doo-dads you can do that as well as programs you can install on a
cell phone or other java-enabled device.
Now it sucks because a lot of people use ssh keys for automation. I think
that there has to be a better way.
Posted Jan 14, 2010 17:25 UTC (Thu) by mmcgrath (subscriber, #44906)
1) No one works with the Fedora Project as their only job. Which means it's likely some people will have to register with two kerberos environments in order to do their day job and work on Fedora. My understanding is that's fairly complex and not all of our contributors are very technical.
2) If someone has my password and ssh key, doesn't kerberos not do anything to protect at that point? That's why we're thinking hardware key, but some of our admins are very opposed to it.
/me invites anyone interested to join the fedora-infrastructure-list and discuss this. It's a topic we take pretty seriously.
Posted Jan 14, 2010 18:08 UTC (Thu) by drag (subscriber, #31333)
Posted Jan 14, 2010 22:15 UTC (Thu) by paulj (subscriber, #341)
Do you mean:
a) 1 user accessing services authenticated via 2 separate Kerberos systems?
b) Kerberos systems co-operating, such that 1 system will accept user
credentials issued by the other?
The former is really easy. The user can authenticate with multiple kerberos
realms quite easily, just by specifying different ticket caches when using kinit
(I open a new session and set KRB5CCNAME).
The latter is cross-realm authentication and requires joint-administrative
fiddling to setup.
I think you mean the former, which is not a problem at all.
Posted Jan 14, 2010 22:26 UTC (Thu) by mmcgrath (subscriber, #44906)
Yeah I mean that. We have kerberos at $DAYJOB. The real concern isn't so much that someone technical (myself) could get it working. But more to make sure that people less technical (say, an art designer in their first year of college) could access both locations without confusion.
Some contributors get confused just generating ssh key pairs.
Posted Jan 14, 2010 22:53 UTC (Thu) by foom (subscriber, #14868)
You call that *easy*??
However, IIRC from last I used kerberos, you can actually kinit to multiple realms just fine without
setting random environment variables.
Posted Jan 15, 2010 12:27 UTC (Fri) by paulj (subscriber, #341)
You need an environment variable really, otherwise every krb5-or-GSS using
client you run needs to have an explicit option (argument, conf file, and/or in the
UI) to specify the ticket cache.
It's not as transparent as using having SSH keys though, unfortunately.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds