On Thursday 17 April 2008, Brian Mathis wrote: > On Tue, Apr 15, 2008 at 8:12 AM, Peter Kjellstrom <cap@xxxxxxxxxx> wrote: > > On Tuesday 15 April 2008, Clint Dilks wrote: > > > 1. Currently all of the key pairs we are using have empty passphrases > > > is it worth the effort of changing this and setting up ssh-agent > > > compared to what you gain in security by doing this ? > > > > To get a clear idea of what keys with no passphrases are like consider > > the idea that users put their regular password in > > /home/$USER/my_passwd.txt > > > > We try our very best to stop any use of key-pairs without passphrase. > > All modern distros have ssh-agents. Using it is trivial, not using it is > > lazy. For extra security use "ssh-add -c" and you'll know when your agent > > is actually signing stuff. > > > > /Peter First, I'm not sure what point (if any) you're trying to make. Did you agree with me, the OP, neither? > This is a HUGE step backwards in security! What is? Not writing comments inline where they belong is confusing. > Now when your system in > compromised, the attacker will be able to get into ALL of the systems > that user has used that password on. Face it, users often use the > same password everywhere. This is really a bad, bad idea. Exactly, very very bad, that was my point. > With password-less SSH keys, at least they only gain access to the > systems with the corresponding key. Just as bad, why would users re-user ssh-keys more often than passwords? > Using an ssh-agent is often not feasible for system-level functions > that need to SSH. Wow, context switch. First we were talking users, now system automation tasks. Quite clearly very different tasks with very different security aspects and trade-offs. IMO this is best done with either a suitable restriction in the authorized_keys file (effectively limiting what you can do with the corresponding private key) or a restricted shell setup (see other post in thread). > Who's going to be there at 2AM to type in the > passphrase when the system reboots? If you script it, then you just > put the plaintext password in a script file again, and now have the > same problem. > > Remember, the old way of doing this was with rsh and .rhosts files, Trusting the host is quite different, this can also be done with ssh (in a much more secure fashion relying on the host-keys, not just the name). > and those were a problem because DNS could more easily be compromised, > and the system tricked into letting you in. SSH keys are meant to get > around THAT problem. No they are not. > Otherwise, all the secret keyfiles are protected > using restrictive permissions, Wrong again, keys are typically protected by encryption. Unix file access bits are just a dumb<tm> idea. /Peter
Attachment:
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ CentOS mailing list CentOS@xxxxxxxxxx http://lists.centos.org/mailman/listinfo/centos
