On Thu, Apr 23, 2015 at 1:22 AM, Philip Hands <phil@xxxxxxxxx> wrote: > Reuben Hawkins <reubenhwk@xxxxxxxxx> writes: > >> On Wed, Apr 22, 2015 at 1:53 PM, Gert Doering <gert@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxx:.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 _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
