Feature request: Multiple containers

[iBobik]

Will be nice to run this container once and be able to login to any other container. Container could be chosed by login (ssh web-container-1@1.2.3.4) and also will be nice to configure permissions (what keys can acces what containers).

[jeroenpeeters]

Hi, thirst of all I want to thank you for your interest in my container-ssh solution. I agree with you on using an authentication model to configure container access over ssh. I will implement that in the future, both using normal password login and public/private key authentication. I cannot give you any time frame unfortunately. Maybe I'll have some time around the holiday season ;)

I don't agree however with your first request. Docker-SSH is a simple service that strictly separates the container access concern from the application container. Accessing multiple containers through the same docker-ssh instance violates this concern and also introduces more complexity. I will not implement it unless I see a very strong use case. If you need access to multiple containers, simply start more instances of Docker-SSH, this is how I do it myself. I think this is the right way, because access to each container is strictly separated. If you have issues with assigning multiple ssh ports on the same host, read up about assigning a network routable ip-address to the container directly. There are many articles about that online, including one of myself (http://jeroenpeeters.nl/deployment/docker/docker-network-containers/).

[iBobik]

Hi, thank you for reply.

Use case for my feature request is: On one server we have multiple applications and some developers needs SSH access to some apps, some needs access to all. I don’t want to run server for all apps, because of memory consumption.

Jan Pobořil

2015-12-08 12:01 GMT+01:00 Jeroen Peeters notifications@github.com:

Hi, thirst of all I want to thank you for your interest in my container-ssh solution. I agree with you on using an authentication model to configure container access over ssh. I will implement that in the future, both using normal password login and public/private key authentication. I cannot give you any time frame unfortunately. Maybe I'll have some time around the holiday season ;)

I don't agree however with your first request. Docker-SSH is a simple service that strictly separates the container access concern from the application container. Accessing multiple containers through the same docker-ssh instance violates this concern and also introduces more complexity. I will not implement it unless I see a very strong use case. If you need access to multiple containers, simply start more instances of Docker-SSH, this is how I do it myself. I think this is the right way, because access to each container is strictly separated. If you have issues with assigning multiple ssh ports on the same host, read up about assigning a network routable ip-address to the container directly. There are many articles about that online, including one of myself ( http://jeroenpeeters.nl/deployment/docker/docker-network-containers/).

— Reply to this email directly or view it on GitHub https://github.com/jeroenpeeters/docker-ssh/issues/4#issuecomment-162850721 .

[pwFoo]

Multi container access sounds great a type of ssh proxy... But maybe could be a security problem and overhead to this project...

[robertoestivill]

So another question related to this topic. Lets say I have three containers running on a development environment, and I want to be able to ssh into all of them in different ssh sessions. I'm guessing that this will not work because all containers will be sharing the same host docker.sock

docker run -d -p 2222:22 \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -e CONTAINER=my-container -e AUTH_MECHANISM=noAuth \
  jeroenpeeters/docker-ssh

What modifications are required on the README command to make this work ?

[jeroenpeeters]

Why do you think this wouldn't work? The docker socket is how Docker exposes its API. The same API is used by the docker command line tool. What wouldn't work though is that you can't map the ssh container's internal port 22 to the same external port for all three instances. The example maps 22 (container internal) to 2222 (external). Solution is to just map to a different external port (like 2222, 2223, 2224 for instance). Another option is to use an approach to give containers a network routable IP so you can actually directly use 22, but that is a completely different ball game.

[bdelbasso]

Hello.

There is a use case for this when you use docker-compose.

Having to add one instance of docker-ssh per service in your docker-compose.yml is cumbersome. Would be great to be able to add only one docker-ssh service that exposes all the containers which it is linked to.

IMHO It does not violate separation of concern if you consider that it provides the SSH service to the multi-container app.

I could work on a PR if we agree on a strategy on this.

[jeroenpeeters]

@bdelbasso The thing is that Docker-SSH now only bridges a shell session with the ssh session. It doesn't do anything 'magical' so to speak. If one Docker-SSH instance needs to provide access to multiple containers it needs to implement some mechanism for the user to select which docker container it connects to.

I do like this simplicity and single responsibility that the current implementation has. However I do recognize the need to connect to multiple containers through one ssh instance. The use case with Docker compose is really a good one.

I see the following possible implementations:

• implement some kind of pseudo shell in which the user selects which container to connect to.
• include the container name in the connections string (ssh user@somecontainer.somehost), but this depends on multiple DNS entries pointing to Docker-SSH

Please let me know if you see other possible implementations. Let's discuss it here, I'm certainly more than willing to incorporate a PR that implements this correctly.

[iBobik]

Another way how to select container:

Include it in the username: container@somehost (will connect to root), container/username@somehost (or any other suitable character)

Jan Pobořil

2016-10-11 9:46 GMT+02:00 Jeroen Peeters notifications@github.com:

@bdelbasso https://github.com/bdelbasso The thing is that Docker-SSH now only bridges a shell session with the ssh session. It doesn't do anything 'magical' so to speak. If one Docker-SSH instance needs to provide access to multiple containers it needs to implement some mechanism for the user to select which docker container it connects to.

I do like this simplicity and single responsibility that the current implementation has. However I do recognize the need to connect to multiple containers through one ssh instance. The use case with Docker compose is really a good one.

I see the following possible implementations:

• implement some kind of pseudo shell in which the user selects which container to connect to.
• include the container name in the connections string (ssh user@somecontainer.somehost), but this depends on multiple DNS entries pointing to Docker-SSH

Please let me know if you see other possible implementations. Let's discuss it here, I'm certainly more than willing to incorporate a PR that implements this correctly.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/jeroenpeeters/docker-ssh/issues/4#issuecomment-252837489, or mute the thread https://github.com/notifications/unsubscribe-auth/AAlfWNAczZI-QSe9778-1eFxwJSLwKYNks5qyz7igaJpZM4GwNgi .

[jeroenpeeters]

@iBobik, I think that is is a better idea. However I think we should keep ssh semantics as similar as possible. So:

• ssh abc@host --> abc is the username, no container selected. Maybe we should have a DEFAULT_CONTAINER environment setting, or this connection attempt will fail if docker-ssh is configured to serve ssh for multiple containers. At least ssh connection string semantics are the same as for any other ssh server.
• ssh user/container@host --> self explanatory. maybe the separator character (/) should be configurable.

[bdelbasso]

Your last proposal sounds pretty good to me.

So we would define these environment settings : MULTI_CONTAINER=yes to enable the ability to select the container from username MULTI_CONTAINER_SEPARATOR=/ (default value)

By default, in multi-container mode, if the container is not specified in the username then we try to use the specified CONTAINER as default container if it is set/it exists (and otherwise don't fail, just refuse connection).

There is one question though about the docker-compose use case: container ids are auto-generated hashes (like 577531590c52) and the name of the service (e.g. web) is prefixed by the name of the app (e.g. my_app) to make the actual image name (e.g. my_app_web).

Thus ssh root/web@my-host will not work out-of-the-box and ssh root/577531590c52@my-host defeats the whole purpose.

Thus it looks like supporting docker-compose is another use-case than "simple" multi-container support. I need to investigate more about what could be the potential solutions.

[jeroenpeeters]

The compose case is a difficult one. My first thought was that you should be able to use the compose service name to select a container. But how would this work if you scale the service to multiple instances? I propose to do the simplest thing first; use the container name or id to select a container. We can later expand it to compose defined services.

[pwFoo]

Would it possible to select the container by use env vars / labels?

I use a revproxy with docker-gen which add all containers with a environment variable "VIRTUAL_HOST" and optional "VIRTUAL_PORT". So each time a start a webserver container the reverse proxy will add it to the configuration automatically.

[dwenzel]

Are there any news on this topic?

[virtimus]

Just did some quick modifications in my fork. Added "cAuth" authorisation verifying only pass and choosing container by user login.