shared private key

[Reuben Hawkins]

On Thu, Apr 23, 2015 at 1:22 AM, Philip Hands <phil at hands.com> wrote:
> Reuben Hawkins <reubenhwk at gmail.com> writes:
>
>> On Wed, Apr 22, 2015 at 1:53 PM, Gert Doering <gert at greenie.muc.de> wrote:
>>> Hi,
>>>
>>> On Wed, Apr 22, 2015 at 01:26:06PM -0700, Reuben Hawkins wrote:
>>>> Let me know if I'm missing something.  :)
>>>
>>> Signed keys from a common CA?
>>
>> I don't think the signed key helps in my particular case (I may be
>> wrong, if so please correct me).
>>
>> I'm working on a management application and the next version's big
>> feature is network security via SSH.  My application is actually
>> backwards from most other client/server models.  It's backwards in
>> that the "server" initiates connections to the "clients" (so the ssh
>> client runs on the "server", sshd on the "clients") to make the
>> clients do things (let's just say run updates as an example).  I need
>> to get the server user's public key into the client's authorized_keys
>> file when the client software is installed.  I can't think of a way to
>> get the public key from the server other than the private key
>> hardcoded into the installer and the corresponding hardcoded public
>> key in the server's authorized_keys file like this...
>
>> command="cat ~/.ssh/id_rsa.pub",other-safty-restrictions ssh-rsa AAAA....
>>
>> With this anybody can get the server user's public key.
>
> I think you need to describe what you're after in terms of which group
> is meant to be generating keys, and what those keys are supposed to be
> trusted to do once everything's running.

Installers will generate keys when the software is installed.  A user
account will be created for the software (like admin-data, similar to
www-data for Apache).  Administration server is going to periodically
regenerate keys for itself and for the clients according to NIST
recommendations.  They keys on the client will be trusted mainly to
run backup jobs.  The user accounts will all be fairly unprivileged,
and the backup binary is setuid.

>
> Is the key that you're interested in transfering being generated by the
> competent people in this arangement, or by the unskilled customers?

The skill level of the customers is a fairly wide range.  Some of them
would know exactly how to do this and other had never heard of SSH.
I'll be generating all the keys for them in the installer script.
They'll have the option to regenerate keys for a host in the admin
user interface, and the admin will periodically (maybe one a year)
regenerate keys.

>
> If the key is being generated by the machine belonging to the unskilled
> customer, then I understand your problem, and the reason for the
> solution, but I'm not quite sure.
>
> It sounds like you have a key on an administration server that you want
> to get to the boxes being administrated.  I presume that the people
> running the admin server can be expected to be a bit more capable?

I generally assume the people running the admin server will be more
capable than the ones installing the clients, but it also can
sometimes be the same person.  It also may be different people in
different companies.  So ssh-copy-id may not be an option because
neither company will want to give password access to the other.  To
work around requiring password access, I'm attempting a solution where
they can just swap public keys on demand and examine the key
fingerprints and optionally reject the public key if it fingerprints
dont look right.

>
> Is there any reason why you cannot simply ship the authorized_keys file
> with your software?  Perhaps GPG signed?  Or publish the GPG signed
> authorized_keys file on your web site?

I think I can't do that.  The authorized_keys file needs to only allow
access to one specific administrator machine, so the client installer
asks for the url/hostname/ip/whatever of the admin machine, then goes
and gets the admin-data user's public key (from
admin-data at admin.example.com:.ssh/id_[rsa|ecdsa|ed25519].pub).
There's also going to be a second key hardcoded into the installer
which will allow the clients to push the /etc/ssh/host_keys to the
admin into a holding area.  The admin will get a notice that there are
pending keys needing approval.  The approval script will show the key
fingerprints, and the admin person will either accept the keys (which
get added to the known hosts for the admin user), or reject the keys.

something like this on the admin...

command="receive-key" ssh-rsa AAAAA...

The receive-key is a binary which parses the keys to ensure nothing
fishy is being uploaded to the pending key directory.  The filename is
a hash of the key value (the AAAA... string) so uploading a key
multiple times only writes to one file.  The comment in the key is
updated with info like $(date), the $SSH_CONNECTION, etc.

So the security of it all depends on command= and a person looking at
key fingerprints.  Maybe this can be improved with signed keys, but I
haven't managed to wrap my head around that yet.  For the clients, and
maybe the administrator machine, the keys are generated at install
time, so there isn't much opportunity to sign the keys.  I don't want
to require our customers to send their keys to us to be signed.


>
> BTW For the case where the clients want to only offer access when they
> feel like it, rather than letting a cron job on the admin-server in
> whenever it feels like it, you could try not having keys on the server,
> and instead use agent forwarding such that the clients only trust a key
> they generated themselves, which they keep to themselves, as described
> in the example here:
>
>   http://wiki.hands.com/howto/passphraseless-ssh/

This is an excellent read!  Thanks!  :)

>
> HTH
>
> Cheers, Phil.
> --
> |)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
> |-|  http://www.hands.com/    http://ftp.uk.debian.org/
> |(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,    GERMANY