Proposal: Add SSH transport protocol

[zedtux]

As I have already describe in the docker-registry repository issue #531 I'd like to authenticate users with their SSH keys like is doing Git today.

This sounds really natural as Docker is already using the commits like in Git.

Pushing with Docker, using SSH, would then looks like the following:

docker push docker@docker.zedroot.org:zedtux/my-docker-image

This needs to have a SSH key management in order order to add/update/remove them and then docker push should accept this new protocol.

[phemmer]

The problem with this is that when you do docker push, the client on your machine connects to the docker server over either a unix domain socket, or tcp. In both cases, the daemon may not be running as the same user who ran docker push, and in the latter case, it might not even be on the same host. Because of this, when the daemon goes to do the push to the registry, it doesn't have access to the client's ssh key.

[zedtux]

One solution would be to pass the path to the folder where the SSH keys are stored, which is a bit annoying, but maybe with a configuration file this could be then better managed.

What do you think about his ?

[phemmer]

You would have to grab the ~/.ssh/id_{rsa,dsa} file and send it off to the daemon. This is a huge security vulnerability. If any software took the liberty of grabbing my ssh private key, that software would not find itself running on my machine.

Aside from the security concern, it's also possible for there to be no ~/.ssh/id_{rsa,dsa} file, and for an ssh key agent running instead. In this case, the only way to use the client's ssh key is to have the ability to connect to the unix domain socket, which isn't accessible if the daemon is running on another host.

[phemmer]

The only possible avenue I could see for this working would be for the client to provide some sort of channel to proxy the ssh key agent. If there is no agent running, it could start one up for the duration of the push.
This way the key never leaves the client. However this would be somewhat complex to do.

See also #6396, which is to open a channel forwarding the ssh key agent to the daemon, but so that it can be accessed by a container. If that is implemented, the same channel could be used for this.

[zedtux]

Thank you for all the information you gave me. Your suggestion looks nice.

[calavera]

Closing this issue. Thanks for reaching out, but it's not among our goals right now to tackle this.

[foxx]

I've gotta say, classifying this as not being an important goal is a pretty damning statement of your security priorities.

[akomm]

This is actually something very important. We got real world examples, some of which were mentioned here, why it is so. And the answer is a one-liner & close? Since when is a "not our goal right now" a close reason at all? Tag it if you think its low priority - at least. Weird close-policies tend to generate equally weird assumptions about reasons behind them.

[theasp]

You can tunnel access to the registry over SSH without any change to docker. The following will connect to a remote machine, and create a tunnel back to localhost:5000 that you can pull over:

ssh other-docker-node -R 5000:127.0.0.1:5000 docker pull localhost:5000/your/image

You can use -L to make a tunnel you can access locally, as long as it's running.:

ssh other-docker-node -L 5000:127.0.0.1:5000  -v -N

[akomm]

@theasp Thank you, but I'm already doing it that way.

It is not the same as transporting & communicating via SSH. While you already authenticate using key you also need to authenticate to docker's own system, because there is only an authorization, but no authentication plugin support / API. From HTTP point of view this makes sense, because to safely authenticate on application level, you first need a secure connection. Then why do authentication on application level, when you can do so in one step while ensuring the secured connection?

The thing is just - and because we have live examples of why I skip the explanation - ssh can simplify the usage of docker and reduce a lot of overhead, make it more lightweight. See an example of gitolite. It is a nice example of plain custom shell and key authentication which enables you to manage and authorize operations on repository for different user (via authorized keys & shell init command bound to those keys) using one non-sudo/adm local OS user.

I understand that based on the current transport implementation of docker, SSH would make a lot of implication and changes needed. And that is why I understand that it can not be provided with a single "snap". I just don't understand why this feature request is closed. It is still relevant - maybe not today, but tomorrow.

[justincormack]

I don't think having this issue open or closed makes much difference, as the issue for registry support for ssh is still open, and for this use case of ssh that would have to be implemented first. If that gets done then we can reopen this. There are other potential uses for ssh with docker, but this issue is not requesting those, so it is dependent on registry support.

[akomm]

@justincormack the registry projects references back to this project with the argument, that it simply relies on the transport of docker, not the other way.

[tetherit]

+1

[cfriedt]

+1

[zedtux]

I actually don't see the point of closing it, keeping it on open means it is on the radar (even if you don't consider it important ... 😳).

What is the cost of keeping it open? People having visibility on it can vote, is that a problem?