[RndTbl] Hey security guys!

Adam Thompson athompso at athompso.net
Thu Mar 20 14:12:30 CDT 2014


 

On 2014-03-20 13:38, Kevin McGregor wrote: 

> We have a pile of
Linux servers here at work. We'd like to set up the shared keys to
simplify admin via SSH. Here's the thing (quoted from an email I
received): 
> 
> We are thinking of putting public/private ssh keys on
all of our Linux servers. 
> 
> The purpose of this is so that our
central admin server can "do stuff' on all of our servers without
needing a password. We are wondering how far to go for convenience. 
>

> Below are restrictions that we can place on the key pair (there may
be others, but these are the ones of which I'm aware). Have a look at
each restriction and consider whether we should use the restriction or
not. Basically it would be most convenient to have none of the
restrictions. 
> 
> · We can create a password on the key pair 
> 
> o
This would defeat the whole purpose of using the key pair to avoid
passwords 
> 
> · We can limit which user can run things on the target
machine 
> 
> o Most likely, we would install the public key for the
user root (therefore things would run as user=root) 
> 
> · We can limit
what commands can be run on the target machine 
> 
> o We would like to
leave this wide open so we can run anything remotely 
> 
> · We can
limit the source machine that can initiate remote commands (ie -
commands can only come from the admin machine) 
> 
> o It would be nice
to not have this limit as we could move the private key onto other
machines (eg a VM on your desktop) to be able to run things remotely 
>

> o The downside is that if anybody gets the private key, they can do
anything 
> 
> Note that firewalls should prevent people from the
internet trying to connect to ssh. 
> 
> [Comments, anyone? -
Kevin]

I'd say you've correctly identified all the upsides and
downsides to key-based authentication, with one major exception (every
human should have their own key, not a single shared key) and one minor
(you can create accounts and require sudo instead of logging in directly
as root). 

I'm going through exactly the same issue right now; having a
centralized directory and authentication server makes your life much,
much easier, even if it's just old-fashioned YP/NIS. That way you have a
consistent UID/userid/password, and on each system you can enforce
whatever policies you want using sudo. Including allowing people to add
their key to /root/.ssh/authorized_keys if necessary. 

It's entirely
normal for some ssh accounts (usually "root") to have a dozen or so
authorized keys, IMHO. 

Now we'll wait for the Shawns/Seans to chime in
and tell us how this is horribly unsecure... 

-Adam 
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.muug.mb.ca/pipermail/roundtable/attachments/20140320/1552a931/attachment.html>


More information about the Roundtable mailing list