An update on the Fedora August 2008 intrusion [LWN.net]

An update on the Fedora August 2008 intrusion

Posted Mar 30, 2009 15:11 UTC (Mon) by melevittfl (guest, #5409)
In reply to: An update on the Fedora August 2008 intrusion by mmcgrath
Parent article: An update on the Fedora August 2008 intrusion

I know this is probably a silly question, but would there be any way to modify SSH to enforce using
passwords on the public keys rather than rely on people following a policy document?

I can't imagine any way to do this with 100% effectiveness because you'd have to trust the client
side to tell you the truth and a determined policy violator could simply build a custom ssh client
that would lie to the server.

Never mind... ;)

An update on the Fedora August 2008 intrusion

Posted Mar 30, 2009 16:13 UTC (Mon) by bfields (subscriber, #19510) [Link]

a determined policy violator could simply build a custom ssh client that would lie to the server.

Well, you're not trying to defend against malicious users--you've already trusted them with access--you're just trying to remind them of policy and protect them against their own mistakes.

An update on the Fedora August 2008 intrusion

Posted Mar 30, 2009 17:48 UTC (Mon) by wmf (guest, #33791) [Link] (1 responses)

Maybe they should use PKI and smart cards. Instead of stolen private keys they'd have completely different problems. :-)

An update on the Fedora August 2008 intrusion

Posted Mar 31, 2009 2:31 UTC (Tue) by motk (guest, #51120) [Link]

I keep suggesting colonic mapping, but nobody listens. the FOOLS.

An update on the Fedora August 2008 intrusion

Posted Mar 30, 2009 18:17 UTC (Mon) by proski (guest, #104) [Link] (1 responses)

I guess it should be possible to require both the public key authentication and the user's password (not the passphrase).

An update on the Fedora August 2008 intrusion

Posted Mar 31, 2009 9:19 UTC (Tue) by muwlgr (guest, #35359) [Link]

From the report, user's password was also compromised and used to run sudo.

An update on the Fedora August 2008 intrusion

Posted Mar 30, 2009 19:28 UTC (Mon) by drag (guest, #31333) [Link]

> I know this is probably a silly question, but would there be any way to modify SSH to enforce using passwords on the public keys rather than rely on people following a policy document?

Nope.

> I can't imagine any way to do this with 100% effectiveness because you'd have to trust the client side to tell you the truth and a determined policy violator could simply build a custom ssh client that would lie to the server.

Ya. Your right.

This is much much better for large orginizations to disable public key authorization support and use Kerberos instead.

An update on the Fedora August 2008 intrusion

Posted Apr 5, 2009 10:42 UTC (Sun) by dlang (guest, #313) [Link] (5 responses)

even if you could force ssh to always require a password, users could put the password into a script wrapper around ssh

also, there are good reasons to not use passwords sometimes. think of cases where you want automated processes to ssh into other systems. there is no user around to type the password in.

An update on the Fedora August 2008 intrusion

Posted Apr 5, 2009 12:01 UTC (Sun) by nix (subscriber, #2304) [Link] (4 responses)

That's a good reason to not use passwords. It's not a good reason to not
use passphrases, thanks to the existence of ssh-agent.

An update on the Fedora August 2008 intrusion

Posted Apr 5, 2009 12:10 UTC (Sun) by dlang (guest, #313) [Link]

if you are dealing with a system that has not had anyone login to it since it was booted anything you do is a variant of 'put the passphrase in a config file'

An update on the Fedora August 2008 intrusion

Posted Apr 6, 2009 2:29 UTC (Mon) by knobunc (guest, #4678) [Link] (2 responses)

Agreed, and to provide helpful pointers to those implementing an ssh-agent based solution:
http://www.enterprisenetworkingplanet.com/netsecur/articl...

(Keychain is wonderful)

-ben

An update on the Fedora August 2008 intrusion

Posted Apr 6, 2009 8:22 UTC (Mon) by dlang (guest, #313) [Link] (1 responses)

keychain works for users (where you can enter the passphrase once per boot), not for tools where you don't have a user to enter the passphrase.

so you end up with either setting up a key that doesn't have a passphrase, or having to store that passphrase in a script (or a bunch of scripts since they don't all run as part of a single user session)

I don't see a big win in security to counter the extra complexity here.

no, this isn't appropriate for cases like what was involved in the Fedora intrusion, but the claim was made (several posts up) that there is no legitimate reason to have a blank passphrase, and that is what I'm disputing.

An update on the Fedora August 2008 intrusion

Posted Apr 6, 2009 12:44 UTC (Mon) by knobunc (guest, #4678) [Link]

Obviously, different environments have different requirements. But I use keychain on my servers. They have months, sometimes years of uptime. If one reboots, I find it acceptable that a human needs to enter a password to allow the box to access the other machines again. I can see scenarios where an unprotected key may make sense but it all depends on the environment.