[RndTbl] Hey security guys!

[Gilbert E. Detillieux]

On 20/03/2014 1:38 PM, 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

That depends on how you'll initiate the commands/scripts that will "do 
stuff".  If they're started manually, you can always use ssh-agent to 
deal with the unencrypted keys as needed.  This would be more secure 
than using a private key that's not encrypted with a passphrase at all.

If you'll be initiating stuff in batch mode, e.g. via cron or at jobs, 
this may not be practical to set up, though.

> · 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)

You could also consider setting this up for non-root user(s) who would 
have password-less access to sudo.  You can then use sudoers to put in 
appropriate restrictions on what each user can run.

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

How often is this likely to change?  Can you look at imposing the 
restrictions based on user/host now, and possibly opening them up only 
if/when it becomes an issue.  (Unless that will create an administrative 
or political nightmare.)

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

If you're talking a very restricted LAN/Intranet, and you trust all your 
users on the inside, you can get away with something more open, of 
course.  But, you are still taking risks.  It's up to you to decide if 
those risks are reasonable/acceptable in your situation.

-- 
Gilbert E. Detillieux		E-mail: <gedetil at muug.mb.ca>
Manitoba UNIX User Group	Web:	http://www.muug.mb.ca/
PO Box 130 St-Boniface		Phone:  (204)474-8161
Winnipeg MB CANADA  R2H 3B4	Fax:    (204)474-7609