Least invasive canonical method to enable SSH for root inside GitLab CE container?

Hi,

in order to work around an issue with Ansible (which has to do with “Docker connections” to dynamically added hosts), I am enabling SSH inside the container also for root. To do this I am currently declaring a bind-mount for /assets/sshd_config which allows me to effectively maintain an outside copy of the sshd_config while being minimally invasive in all other aspects. (One more thing is that docker cp requires a running container and so the bind-mount is a method to sidestep this limitation.)

The way I do it is by creating an SSH key pair meant to be used solely between Docker host and container inside a volume mounted on /root/.ssh inside the container. I then modify /root/.ssh/authorized_keys to list said key.

Additionally I am inserting the following lines (at the end of sshd_config):

Match Address 172.17.0.0/16
    PermitRootLogin prohibit-password
    AllowUsers root

I always verified the effect of my changes using:

$(which sshd) -Tf /assets/sshd_config

This works as expected and adding the container dynamically to my inventory (via Ansible’s add_host) works as well.

I have looked into the issue and pondered what would be the least invasive option for me.

Is there one that is even less invasive than the one outlined above? The method I came up with should survive upgrading the container to a newer GitLab version, but obviously certain changes to the upstream sshd_config could conceivably undo my efforts.

Another option would have been to run a secondary sshd on another IPv4 address while limiting the address to which the preconfigured sshd binds. But I can’t see how that is any less invasive. The only utility it would provide is a separation from the sshd that also serves the GitLab users. But in my opinion OpenSSH has a brilliant security track record and so I trust it to not let me down.

Yet another option I’ve considered was to place the sshd_config into /etc/gitlab (after all the keys live there already) and manipulate /opt/gitlab/sv/sshd/run (e.g. also by bind-mounting), but that seemed more invasive and more brittle, considering the necessity for upgrading to newer GitLab versions.

Any insights you have would be greatly appreciated. Many thanks for reading.

Oliver