On Thu, Sep 10, 2015 at 6:05 AM, Igor Bukanov <igor@xxxxxxxx> 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.) _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
