[RndTbl] Hey security guys!

[Sean Cody]

Someone mentioned to me that I have been invoked. :)

Shared private keys are bad... very very bad (hey you were prescient!). 
The only difference between a shared private key is that you don't write 
it down or memorize it like a password but essentially that's what you 
are implementing... lazy passwords.

Luckily you can manage this pretty readily, the suggestions regarding 
salt, puppet et. al are very good ones and in the past (and working 
present) I handle it via deploy scripts.

Root passwords should be unique and hard to type, that last part is 
mitigated by a shared secret to a password locker (say KeePass).  
KeePass isn't _awesome_ but it's VERY servicable and usable and portable 
enough for most folks (especially GUI addicts).

For root access however... sudo is your friend.  You can do similar 
nutty things like sock-auth or ldap-lookup authorization but 
operationally the password check serves a very important purpose in that 
it makes you think before you act AND gives you an out.  Sudo with 
NOPASSWD is a good way to frequently test your backup system but 
selective use for known
low risk operations can be had.  If you need help with sudo, ask me off 
list or pick up the book Sudo Mastery which I tech edited (uncredited 
because I couldn't finish it in time, yeah I suck) and is VERY good (as 
is SSH Mastery, for which I did finish on time).

So for convenience setup the 'low risk' tools with sudo+NOPASSWD and 
allow users via created accounts and adding them to 
.ssh/authorized_keys...

hint..   ssh user at host 'ssh-add -L >> ~/.ssh/authorized_keys' or if you 
are deploying for people...
ssh host 'sudo mkuser <BLAH>'
cat ~user/.ssh/id_rsa.pub | 'ssh user at host cat >> 
~/.ssh/authorized_keys'

I've in the past created systems (especially for code control) where the 
users didn't know their passwords on the system and we used _ONLY_ had 
access via authorized keys.  Some users had shell access and limited 
sudo NOPASSWD rights (for say cycling a web server, or equally innocuous 
stuff).  Others had forced
commands for accessing the version control software only.  Removing 
users was just removing their authorized_key and it was permanent 
because they had no access or ability to access/change their local 
system account password.

There is also a newer OpenSSH feature called AuthenticationMethods where 
you can specify that you must have BOTH public key & plain-text password 
challenges before allowing access (ie. forced two factor, three if your 
key is encrypted... and it should be RIGHT?).  Another recent feature is 
the concept of certificates with SSH, _similar_ but not the same as SSL 
certificates you can make access decisions based on SSH certificate 
signing authorities as opposed to 'known keys.'  Either of these are 
only useful if you are current with OpenSSH and are not necessarily 
portable given many vendors lackadaisical approach to updating OpenSSH.

As for adding _people_ to root's authorized_keys... don't do it... 
please.  Only add system<-->system keys if you must... I usually create 
service accounts that have specific sudo rights to do what is required 
and those accounts have authorized keys (ie. mirror accounts to ssh 
'sudo tar -zcpf - /' > backup.tgz or forced command for same).  Service 
accounts are created with ridiculously high entropy passwords I never 
record (eg. 'openssl rand 1024 | openssl dgst -sha1 | cut -f2 -d\ ').

Don't be afraid of sudo... you have a built in audit trail when using it 
so embrace that.  As well don't make it easy for plausible deniability, 
map individual actions to audit-able accounts/tools.

All of the above isn't necessarily 'best practices' but practices I am 
comfortable putting my weight behind and support.

The process/policy wonk says this should be documented pretty heavily 
before implementing as you'll want to consider all the corner cases 
(with respect to sudo NOPASSWD).  Once you do, it will pay off VERY 
quickly especially since the above is portable across all reasonable 
UNIXs and maybe even Windows (the whatever the current replacement for 
SFU does exist but I've been too lazy to install the 400MB MSI).

Anyways, time to vanish back into the mists.  Contact me off lists for 
more details/questions/recommendations.

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]
> _______________________________________________
> Roundtable mailing list
> Roundtable at muug.mb.ca
> http://www.muug.mb.ca/mailman/listinfo/roundtable

-- 
Sean