[CentOS] SSH Question relating to Public and Private Keys

Thu Apr 17 12:56:51 UTC 2008
Peter Kjellstrom <cap at nsc.liu.se>

On Thursday 17 April 2008, Brian Mathis wrote:
> On Tue, Apr 15, 2008 at 8:12 AM, Peter Kjellstrom <cap at nsc.liu.se> 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 

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 

> 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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.centos.org/pipermail/centos/attachments/20080417/ba2d3273/attachment-0005.sig>