<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN">
<html><body>
<p>On 2014-03-20 13:38, Kevin McGregor wrote:</p>
<blockquote type="cite" style="padding-left:5px; border-left:#1010ff 2px solid; margin-left:5px; width:100%"><!-- html ignored --><!-- head ignored --><!-- meta ignored -->
<div dir="ltr">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):
<div> </div>
<div>
<p class="MsoNormal">We are thinking of putting public/private ssh keys on all of our Linux servers.</p>
<p class="MsoNormal">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.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">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. </p>
<p><span style="font-family: Symbol;">·<span style="font-size: 7pt;"> </span></span>We can create a password on the key pair</p>
<p style="margin-left: 1in;"><span>o<span style="font-size: 7pt;"> </span></span>This would defeat the whole purpose of using the key pair to avoid passwords</p>
<p><span style="font-family: Symbol;">·<span style="font-size: 7pt;"> </span></span>We can limit which user can run things on the target machine</p>
<p style="margin-left: 1in;"><span>o<span style="font-size: 7pt;"> </span></span>Most likely, we would install the public key for the user root (therefore things would run as user=root)</p>
<p><span style="font-family: Symbol;">·<span style="font-size: 7pt;"> </span></span>We can limit what commands can be run on the target machine</p>
<p style="margin-left: 1in;"><span>o<span style="font-size: 7pt;"> </span></span>We would like to leave this wide open so we can run anything remotely</p>
<p><span style="font-family: Symbol;">·<span style="font-size: 7pt;"> </span></span>We can limit the source machine that can initiate remote commands (ie – commands can only come from the admin machine)</p>
<p style="margin-left: 1in;"><span>o<span style="font-size: 7pt;"> </span></span>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</p>
<p style="margin-left: 1in;"><span>o<span style="font-size: 7pt;"> </span></span>The downside is that if anybody gets the private key, they can do anything</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Note that firewalls should prevent people from the internet trying to connect to ssh.</p>
</div>
<div> </div>
<div>[Comments, anyone? - Kevin]</div>
</div>
</blockquote>
<p>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).</p>
<p>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.</p>
<p>It's entirely normal for some ssh accounts (usually "root") to have a dozen or so authorized keys, IMHO.</p>
<p>Now we'll wait for the Shawns/Seans to chime in and tell us how this is horribly unsecure...</p>
<p>-Adam</p>
<div> </div>
</body></html>