Multiples users single container

[lightoyou]

Hi team,
I'm using this project for a use case Dynamic lab environment.
I developed my own Authorization/Configuration server.

I'd like to know if for this type of use case, users can have several SSH connections on the same container in a simulated way. The idea is that the server doesn't start several container instances for the same user. Indeed, Users are not necessarily experts in the use of screen / tmux.. ( I'm currently using docker as backend)

Do you have any ideas on how to do this?

Thank you in advance for your answers.
Best regards,
Vincent

[bencurio]

Hi!

Thank you for the suggestion! Currently, this isn't possible. However, the idea of semi-persistent containers has come up, especially in the context of GitLab CI. We found that the GitLab CI runner starts a completely new SSH session for each job, so in this case, the setup of having the GitLab CI runner use ContainerSSH as an SSH doesn't work. We were considering connecting SSH sessions based on some environmental variables, which would likely work for your use case, but there hasn't been any progress on this front yet.

Related issue: #61

Best regards,
Bence

[janosdebugs]

Hi @lightoyou, expanding on what @bencurio said, this would require ContainerSSH to track which containers are still in use, possibly across multiple instances, which would require a database. However, nothing prevents you from doing separate contaienrs with the Docker backend with namespace sharing (e.g. network namespace, shared drives, pid namespace, etc). This should have the same effect as using the same containers. The caveat is that you may have to create a separate "persistent" container that the "user" contaienrs can join into and manage its lifecycle from the auth/config server.

[lightoyou]

Hello team,

Thank you for your reply and your time. SSHproxy is indeed a solution. We finally found a solution by defining the "connection" mode which allows to launch several SSH sessions within the same connection:

ssh -f -M -S /tmp/myconnection foo@localhost -p 2222 sleep infinity
ssh -S /tmp/myconnection  - 
ssh -S /tmp/myconnection -O exit 

It's a nice work around for the moment. Indeed, maybe if you have the time you can plan to create this feature as option this could be a nice thing.

Nice job with this project, you can close the issue :) .

Regards.

[tsipinakis]

I can also mention that there has been an (unfinished) attempt to implement this as it's a frequently requested feature. However the focus has been on the Kubernetes backend as we can use the kubernetes object store as the database @janosdebugs mentioned to store the user information. We'd have to use something similar for the Docker version.

I'll re-open this as it's a feature I am interested to track the progress on this (and it's something I'd like to see implemented as well).

If anyone is interested to take this over and bring it to completion you are very welcome to do so, feel free to ping me for questions/advice. You can find the current attempt at implementation here. It's functional, however it needs to be verified whether there are any race conditions/timing issues with the current code.

[janosdebugs]

@tsipinakis this holds a lot of possibilities for race conditons, especially with multiple ContainerSSH instances.

[tsipinakis]

@tsipinakis this holds a lot of possibilities for race conditons, especially with multiple ContainerSSH instances.

The K8s object store already has a conflict resolution process and has some features to address this, (e.g. for multiple operator instances to act on the same objects). The question that is remaining here is if we can leverage that to address this usecase.