Review of pool-wide ssh design #184

Activity

1. thomassa commented on Jan 26, 2016

   

   thomassa

   on Jan 26, 2016

   More actions

   Mistake?

   host.ssh_public_host_key ... should be added to the 'known_hosts' field of any other host wishing to ssh to this host.

   I think that was meant to be s/field/file/ there.
   /etc/ssh/ssh_known_hosts or /home/xapi/.ssh/known_hosts or some other user's known_hosts...

   Small detail of implementation:

   To make sshd reread its configuration file we don't have to restart it: we can send it a SIGHUP. (Although maybe it would be good to restart anyway? Do we want to kill existing ssh sessions or not?)

   Key revocation

   It would be simpler to do without Pool.revoked_authentication_keys and make the thread that watches ssh_ready call a function that just makes the relevant user's ~/.ssh/authorized_keys exactly the same as the list of Host.ssh_public_host_keys of all the hosts.

   I would favour doing it that way if we have a purpose-specific user as which these ssh connections are made: if an admin wants to configure the host to allow other humans or services to make key-based ssh connections, those connections will have to be as some other user(s) using a different file of authorised keys.

   The alternative would be harder: the function called when ssh_read=false would have to read the authorized_keys file as well as writing to it; it would have to add only the host keys not already present, and remove the revoked keys. Much easier and more reliable to just write a new file.
2. jonludlam commented on Jan 26, 2016

   

   jonludlam

   on Jan 26, 2016

   ContributorAuthor

   More actions

   re field/file, good spot thanks.

   As far as the revocation goes, I think I agree, let's just make the authorized_keys == \sum host.ssh_authentication_public_key

   Also, let's go for the 'new user' thing. One last think I was considering - perhaps we could add a pool-wide 'additional_authorized_keys' list? one that an API user could add and remove from? That'd be very handy.
3. thomassa commented on Jan 26, 2016

   

   thomassa

   on Jan 26, 2016

   More actions

   User and privilege

   I think conceptually we probably still want something similar to the "call-plugin" concept: we don't want to give the SMAPI backend unrestricted authority to do anything and everything on other hosts, but only to make those hosts run certain scripts or actions.

   So could we define a user account like "plugin_user" or even "remote_smapi"?

   Then for that user to invoke actions that require higher privileges, perhaps a suitably configured arrangement based on sudo or userv.

   userv looks very nice for this sort of use-case, but doesn't seem to be a standard part of CentOS.
   Overview in slides 10-13 of http://www.chiark.greenend.org.uk/~ian/userv/talk-1998-jun-manchester.ps
   Home page: http://www.chiark.greenend.org.uk/~ian/userv/
   Git source: http://www.chiark.greenend.org.uk/ucgi/~ian/git/userv-utils.git/
4. thomassa commented on Jan 26, 2016

   

   thomassa

   on Jan 26, 2016

   More actions

   We can also restrict the relevant user's privileges in some other ways, e.g.

   • using the ForceCommand option in sshd_config
   • setting something restrictive as the user's login shell
5. jonludlam commented on Jan 26, 2016

   

   jonludlam

   on Jan 26, 2016

   ContributorAuthor

   More actions

   I can see this being used more widely than smapiv3, so I'd go for a more generic 'xapi' user or something similar. Sudo gives quite configurable control over what can be executed, so we could set that up to only allow to sudo execute files within a particular path or something similar?