Re: SSH Question relating to Public and Private Keys

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



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

[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux