On Thu, Sep 10, 2015 at 6:05 AM, Igor Bukanov <igor at mir2.org>
wrote:> Hello,
>
> In my setup I use ssh running on the host to login into different
> containers. As users in the containers are not known to the host, to
> support that I use a dummy user per container on the host with a database
> that maps public keys into container users. Then I use the `command` option
> for authorized keys to invoke a command that connects to the container
> where one of the arguments is the username inferred from the key.
>
> This works (and thanks for recent changes to support AuthorizedKeysCommand
> custom arguments made things even simpler!), but it has few drawbacks.
>
> As I want to allow to use the same public key to login to different
> containers, I cannot use `root` for a dummy user. But since operations with
> containers are privileged, I have to use setuid/setguid command to
> eventually start a process in the container from the process under a dummy
> user account on host. Another problem is that those dummy users should be
> created on the host. This complicates container setup.
>
> So would it be possible to add an options to sshd_command to run
> ForceCommand under a different user than the one that tries to login? This
> will resolve the first concern. Another option would be to allow to use
> non-system user names with sshd trusting that AuthorizedKeysCommand and
> ForceCommand would do the proper job with user verification.
I think you're painting yourself into a corner, and trying to fix it
by stapling a potentially complex and security sensitive toolkit into
a stable application. If you have well defined user list in your
containers running well defined commands with alternative usernames
and privileges, why can't you activate a well defined "sudo"
privilege
for precisely that action? This avoids the setuid/setgid problem well,
and helps even allows runing shell scrupts. (Linux OS's, at least, do
not support setuid shell scripts.)