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]
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
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.
Use chef/puppet/ansible/fuckingshellscripts.org and distribute individual keys to the appropriate user accounts. Then you can manage keys/sudo/centralized auth much easier.
Sean
On Thu, Mar 20, 2014 at 1:38 PM, Kevin McGregor kevin.a.mcgregor@gmail.comwrote:
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@muug.mb.ca http://www.muug.mb.ca/mailman/listinfo/roundtable
I'll chime in with salt stack. Take a look, it has the ability to do what you want, plus more.
Also, I use openssh-lpk on my systems, which allows the public key to be looked up via ldap based in the user id. On 2014-03-20 2:21 PM, "Sean Walberg" sean@ertw.com wrote:
Use chef/puppet/ansible/fuckingshellscripts.org and distribute individual keys to the appropriate user accounts. Then you can manage keys/sudo/centralized auth much easier.
Sean
On Thu, Mar 20, 2014 at 1:38 PM, Kevin McGregor < kevin.a.mcgregor@gmail.com> 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@muug.mb.ca http://www.muug.mb.ca/mailman/listinfo/roundtable
-- Sean Walberg sean@ertw.com http://ertw.com/
Roundtable mailing list Roundtable@muug.mb.ca http://www.muug.mb.ca/mailman/listinfo/roundtable
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@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@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@muug.mb.ca http://www.muug.mb.ca/mailman/listinfo/roundtable
On 2014-03-24 15:03, Sean Cody wrote:
Service accounts are created with ridiculously high entropy passwords I never record (eg. 'openssl rand 1024 | openssl dgst -sha1 | cut -f2 -d\ ').
Since Adam will undoubtedly catch this... this should read 'reasonably high entropy' given digests are a-z0-9 so the language space is reasonable entropy and (depending on who you talk to) mitigated by large string length.
You can just use 'openssl rand -base 64 1024' and combine the line feeds and get an additional 8 bits of entropy or strings < /dev/urandom blah blah blah. It all comes down to... make it random, complicated, and ridiculously annoying to type. This way you make the mechanism easier to use than just doing it manually. :)
-
Adam Thompson -
Gilbert E. Detillieux -
Kevin McGregor -
Robert Keizer -
Sean Cody -
Sean Walberg