> This allows you to have a single ssh process on the normal ssh port which places user sessions into their own individual docker containers in a secure and locked down manor.
Funniest instance of this misused homonym I've seen.
Ah, I've been out-pedanted. Yeah, I realized a while after posting. Looking at Wikipedia and some dictionaries, it looks like homonym doesn't always imply same spelling. Homophone would be more correct though.
I'm not sure if this is related -- because it doesn't require Docker or Linux -- but I've got a small shell tool for transparent development on remote machines. Gives you the ability to do something similiar (`ws shell`), and drop directly into the remote environment you're working in.
I use it to work on my Mac, but develop on a Linux box:
To shamelessly plug a much more minimalist solution, https://github.com/polydawn/siphon-cli can also give you new shells shells inside existing containers (or whatever; it's more like screen than anything tightly bound to docker).
Siphon does nothing but create and forward psuedoterminals, so it has a lot less features to directly interact with docker than dockersh appears to have, but it's also able to do its job without root or any priviledged syscalls, and doesn't rely on any knowledge of kernel namespaces at all. Which is more useful may depend on your perspective and usecases.
The point is not containerization with Docker (vs. something else), but showing a project that can be used as a login shell. I.e. I think a good chunk of the challenge was gluing everything from sshd to the running individual containers.
Even if you were saying that such a login shell already exists with another containerization scheme, the fact it uses Docker is relevant to those who are investing in Docker. For instance Dockersh can be configured to run the shell in a specific Docker image; that is you can re-use your existing knowlegde and tooling.
Sometimes, during development or when fixing a deployed app, you want to get inside the container environment to poke around. Just to work out why the hell something did or didn't happen.
Right now it is difficult. Docker doesn't support it directly. There is a lot of demand for it:
Are you sure it is related to entering an existing container (and running a new process) ?
From reading the README file, it seemed to me it was only spawning a login shell process in a new container (not an existing one), and possibly resuming an existing container.
I feel this docker pain. But isn't an isolated process the point? I thought I read an article here recently that said, basically, if you're running an ssh server in your proc then you're doing it wrong.
> This allows you to have a single ssh process on the normal ssh port which places user sessions into their own individual docker containers in a secure and locked down manner.
No! Warning!
Docker is not secure and locked down. Do not use this for "security".
Funniest instance of this misused homonym I've seen.