[GLLUG] ssh key distribution tools

[tid]

Thanks for all your responses. I'm going with ssh-copy-id in the short term
and looking at cf3 for a longer-term solution. Anyone got any
recommendations / avoids for puppet / chef and cfengine? Caveat : I'm a
somewhat dyed-in-the-wool sysadmin and have no real desire to become a
'devops' or spend the rest of my life writing ruby scripts, if I can avoid
them.

Tid


On 6 March 2014 15:16, Philip Hands <phil at hands.com> wrote:

> tid <td at bloogaloo.co.uk> writes:
>
> > Hi Folks,
> >
> > I have a group of developers ( 12 ) who ssh into ~60 boxes using a few
> > shared keys.
>
> "shared keys" -- that doesn't sound right -- I'd generally recommend not
> even sharing one's own key between multiple machines, let alone sharing
> one key between multiple people.
>
> > I'm looking for a steer on applications that can push out a set of
> > public keys based on a limited set of criteria
>
> There's cf3 (the much less annoying version of cfengine), since chef and
> pupped got a mention -- cfengine is really lightweight especially if you
> don't bother with the file server bit, but all these seem like overkill
> for what you're asking for.
>
> If it's really only keys that you're worried about, then you could
> probably do worse than having all the machines pull from a git repo, and
> then have a script that cats lists of public keys into the relevant
> authorized_keys files on the basis of whatever criteria you fancy.  I'd
> have thought that you'd just need a few text files mapping machine names
> to classes, and classes to names for authorised users.
>
> For bonus points, make the script check for a GPG signed tag before
> trusting updates.
>
> > - anyone got any recommendations? I'm not really looking for fully
> > fledged LDAP services or anything too heavyweight as the target
> > machines are locked down behind firewalls ( and draconian firewall
> > teams ) so only ssh is available to me.
>
> The git repo can certainly be pushed out via ssh, or could be pulled
> regularly from central git repo(s) -- if you're pushing via git, you
> could do all the work in a post-update hook, and not need to bother with
> cron.
>
> Bonus points for ensuring that a broken update will not lock you out of
> all machines (or that a machine with a full disk will not delete all the
> keys and then have no room for the new files ... a create and move
> approach, with error checking everywhere should deal with that problem)
>
> BTW it's possible to list multiple URLs in a git remote, so you can
> define 'all_hosts' say, and when you push to that it'll go through all
> the URLs in sequence.
>
> The downside of using git is that all the remotes will have a full
> description of who's allowed to log into what, which might not be what
> you want, particularly if some of the hosts have poor physical security,
> say.
>
> Cheers, Phil.
> --
> |)|  Philip Hands [+44 (0)20 8530 9560]    http://www.hands.com/
> |-|  HANDS.COM Ltd.                    http://ftp.uk.debian.org/
> |(|  10 Onslow Gardens, South Woodford, London  E18 1NE  ENGLAND
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.lug.org.uk/pipermail/gllug/attachments/20140311/5eaea69c/attachment.html>