DSM 7.1 Clean way to support remote Docker CLI (e.g., docker --host ssh://root@DSM-HOST …)

[whxvd]

Hi!

In the following, let DSM-HOST be the address of a Synology DSM 7.1 host running the official Docker package. As long as pubkey authentication is set up, the docker CLI usually supports connecting to Docker daemons on other hosts via SSH, e.g., by docker --host ssh://root@HOST …. However,

docker --host ssh://root@DSM-HOST …

does not work, because the output of

echo 'echo $PATH' | ssh root@DSM-HOST sh

reveals the path to be /usr/bin:/bin:/usr/sbin:/sbin, and that does not provide for finding /usr/local/bin/docker.

There are various ways around it. But I did not find one without tampering the internals of the DSM-HOST. E.g., by creating a symlink from /usr/bin/docker to /usr/local/bin/docker on the DSM-HOST. Or by changing the /etc/ssh/sshd_config on the DSM-HOST.

Is there a known "tamper-free" way to enable remote Docker CLI support to a host running DSM? And if not, what may be the least intrusive way of accomplish the aim? Or is, e.g., creating a link from /usr/local/bin/docker to /usr/bin/docker no tampering at all?

Best wishes
Sebastian

 

[one-eyed-king]

You need to create a symlink on your ds for it to work:

 sudo ln -s /usr/local/bin/docker /usr/bin/docker

That's what I would do:

On DS:

• add my admin user (!=root) to the docker group to permit access to the docker.sock
• add my admin user to the admistrators group to permit ssh login
• setup keypair-based authentification for that user (credential based-auth is not an option...)

On remote host:

• create a docker context for the ds on the remote host: docker context create myds --docker "host=ssh://{user}@{host or ip}"
• use the created context on the remote host: docker context use myds
• use your docker commands as usually (this will fail if the symlink was not created on the ds or the matching private key is not exposed via pagent)
• once everything is done, change the context back: docker context use default

 

[whxvd]

Hi @one-eyed-king! Thank you for the answer.

You need to create a symlink on your ds for it to work:

 sudo ln -s /usr/local/bin/docker /usr/bin/docker

That is basically what I already did. However, I was wondering whether that may introduce problems in some future. I do not know what DSM expects (not) to be in, e.g., /usr/bin. I do not own the DS in question and don't want introduce any future problems. Do you know whether it is certain that, e.g., future DSM upgrades or package updates will produce no spurious errors, when I create that link in /usr/bin?

 

[one-eyed-king]

/usr/local/bin/docker itself is just symlink created when the docker package is started, and removed when the docker package is stopped. If the Docker package is started, it points to the docker binary, regardless on which volume it is installed.

I lack the imagination, that creating a symlink that points to another symlink would cause side effects.
What worse can happen other than the symlink being removed or the target of the symlink being relocated?

Though, you can always secure the engine using a https endpoint and certificate based authentication. It would require to expose the endpoint to the remote user (over the internet?), and should only be used in combination with certificate based authentication. It would have the advantage that remote user could control the docker engine without require ssh access to the host (which is by no means a protection against the user being able to enable ssh access for himself).

 

[whxvd]

/usr/local/bin/docker itself is just symlink created when the docker package is started, and removed when the docker package is stopped. If the Docker package is started, it points to the docker binary, regardless on which volume it is installed.

That is interesting to know. Thank you!

I lack the imagination, that creating a symlink that points to another symlink would cause side effects.
What worse can happen other than the symlink being removed or the target of the symlink being relocated?

Probably nothing. And after some further consideration, I feel safe enough with the symlink. My imagination was that, maybe, e.g., a future version of DSM for some reason includes Docker (CLI) in its core, wants to install it to /usr/bin/docker, finds that place occupied, and instead of just overwriting it, does something that is totally intransparent to the actual owner (not me) of the DS.

Though, you can always secure the engine using a https endpoint and certificate based authentication. It would require to expose the endpoint to the remote user (over the internet?), and should only be used in combination with certificate based authentication. It would have the advantage that remote user could control the docker engine without require ssh access to the host (which is by no means a protection against the user being able to enable ssh access for himself).

Yes, that is an option. But for now, I do not want to invest the time to become proficient enough with the TLS/certificate stuff.

I will stick to the symlink for the foreseeable future. Thank you!

All the best
Sebastian