Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow defining start/stop command setting per connection #3

Open
kwibus opened this issue Nov 22, 2020 · 4 comments
Open

Allow defining start/stop command setting per connection #3

kwibus opened this issue Nov 22, 2020 · 4 comments

Comments

@kwibus
Copy link
Member

kwibus commented Nov 22, 2020

Now gucamole-trigger settings apply to all connections.
But you might want only use this plugin on some connections.
Or have different command for different connections.

This is easy to do for default authentication via user-mappings.xml.
But have to find out you can make it so you can also set it via mysql/posgress etc authentication

@adb014
Copy link

adb014 commented Jun 20, 2023

Yes I have a problem like this as well. I have both RDP and SSH connections, and I use "ForceCommand docker start --attach --interactive " in the sshd_config file to start the container. This allows both Guacamole and normal SSH clients to use the containers. So I only need guacamole-trigger for the RDP connections. What I'm currently doing is using hostnames like "cnt1-ssh" and "cnt2-rdp" then ignoring the START_COMMAND (and STOP_COMMAND for what it matters) if the hostname ends in "-ssh".

The issue with this is that my containers aren't in the same docker network as the guacamole, for security reasons. Therefore using the hostname means that I also need a DNS as well in the same network as the guacamole to resolve the hostnames to IP.

It would be so much easier if guacamole-trigger also exported the profile name so the START_COMMAND can see it rather than just hostname and guacamoleUsername.. I could then easily use the container name as the name of the profile and filter on that and leave the hostname with the correct IP addresses, and no longer need a local DNS

@kwibus
Copy link
Member Author

kwibus commented Jun 20, 2023

Yes. I agree that would be nice. I am also looking for a way to specify START_COMMAND options per connect.

It might be possible to pass all protocol option, and connection name to the script. hopefully this include made up protocol options. But have to lookup how that works with different authentication plugins.

another thing to consider is the stop command. now it checks if multiple people/connections logged in into the same machine.
It only runs stop command if the number of connection to a host drop to 0. If you give different names to the same host.
it will see them as 2 different hosts, So it might stop the host even if there other connections still using it.

Also if multiple connections start/stop the same host. but have different options. might be hard to debug.
So i have to think about it how i will do this.

But about your use case.

If i understand you correctly:

  • You want to start containers that you can connect to with both "ssh" and RDP.
  • You prefer to connect over IP

What is the problem with starting the container with both ssh and RDP connection?
this way it does not matter if you are logged in first with ssh or rdp. they will both start stop it based on use.

Do you use tools like kubernetes, docker-compose docker swarm?
Can you share the config files for your setup. so i might be able to reproduce the issue

@adb014
Copy link

adb014 commented Jun 21, 2023

Sorry I wasn't really clear in my use case. I'm using only docker with bash script for the orchestration. The reason for this are

  • The behaviour of the platform needs a lot of other changes dynamically when new users or modules are added and these changes impact things on the host and within existing containers, so composer won't help me
  • I'm an old codger and bash works perfectly fine for my scripting needs ;-)

The containers for guacamole, gaucd and postgresql are all in a service network and the guacamole is only exposed to the users behind a reverse proxy. This service network was created with

docker network create service

Now imagine if the gateway for the network "service" is 172.19.0.1, basically what I'm doing when I add a user to the platform is

_port=3389
...
adduser -G users user1
update_guac_passwd user1 # Basically a script using the same password injected in the the postgresql
docker network create user1
docker volume create user1
docker create --network=user1 --volume user1:/home/user --name=user1-rdp .... -p 172.19.0.1:${_port}:3389 container /usr/init.d/xrdp start
docker create --network=user1 ---volume1 user1:/home/user -name=user1-ssh .... container /bin/bash
_port=$((_port+1))

and the user after that

adduser -G users user2
update_guac_passwd user2
docker network create user2
docker volume create user2
docker create --network=user2 --volume user2:/home/user --name=user2-rdp .... -p 172.19.0.1:${_port}:3389 container /usr/init.d/xrdp start
docker create --network=user2 --volume user2:/home/user --name=user2-ssh .... container /bin/bash
_port=$((_port+1))

The ssh and rdp containers are the same.. The ssh container is used with the openssh config as

Match Group users
        X11Forwarding no
        AllowTcpForwarding no
        ForceCommand  /usr/local/bin/docker start --attach --interactive $USER-ssh

In the host machines configuration so the user have real accounts on the local machine. As ssh/rdp to isolated containers are the only means supplied to the user to connect to the machine this is not a problem , and the SSH containers are destroyed by the use of the TMOUT bash environment variable to kill the shell after an idle time.

Each user is isolated in their own network for security reasons and with a little iptables magic on the DOCKER_USER chain each user can only see a dedicated reverse proxy exposing only what I want them to see. As the containers user1-* and user2-* are not in the "service" network I expose their RDP port to the guacd on the gateway of the "service" network, with port number incrementing from 3389. The guacamole and gaucd containers therefore can't use docker hostname resolution to find the user machines IP addresses.

Now the issue is that guacamole-trigger only passes the "hostname" variable to the START_COMMAND script.. So the hostname must contain an indication to the START_COMMAND script of what container to start. Here "user1-rdp" or "user2-rdp". For me the hostnames all point to the "service" network gateway of "172.19.0.1" but with different ports..

At the moment I'm using dnsmasq with a hosts file

172.19.0.1  user1-rdp user1-ssh user2-rdp user2-ssh

So that the START_COMMAND script can have a hostname that determines the container to start and the guacamole and guacd can do a DNS lookup from these hostnames and always get the service network gateway.

If guacamole-trigger was modified to also pass the "name" field of the connection profile, I could keep the hostname as the correct IP address and choose the container to start based on the "name" field and so get rid of the dnsmasq server.

PS: Yes I could use START_COMMAND to start the SSH container as well and modify the "ForceCommand" of openssh to run "docker exec -it .... $USER-ssh bash" instead, but this would mean that normal ssh is no longer possible.

@kwibus
Copy link
Member Author

kwibus commented Jun 22, 2023

With latest version that i also mentions in #5.
It will now pass protocol and all other connection attributes.
those depend on protocol you choose.
You can also add dummy attributes to you connection config that would be passed to you start/stop scripts
But how to this depends on authentication provider used.

For your use case protocol would work to detect ssh.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants