bolkedebruin / rdpgw

Remote Desktop Gateway in Go for deploying on Linux/BSD/Kubernetes
Apache License 2.0
732 stars 117 forks source link

Installation Doc #16

Open maop opened 3 years ago

maop commented 3 years ago

Hello!

This project looks very promissing, i only have seen guacamole server which a very huge frankenstein and so complex...

Your RDP GW looks awesome, but i just can't figure out how to install it, is there any tutorial, installation documentation, or a blog post, etc? i'm unfamiliar with Keycloak how should i configure it to work with rdpgw? can you point me to the right path plz?

I have a Debian KVM server with several windows VM's, currently i'm just port forwarding the RDP ports to each VM, but i'd love to use your software as a frontend to all of that.

Kudos for your project!

Hope to hear back from you...

Best regards.

bolkedebruin commented 3 years ago

Hi @maop

It might warrant a INSTALL doc indeed. Let’s see if we can work out the beginnings here.

First you would need to compile the binary. For this you need the “go” compiler installed on your system. And then you clone the repository (git clone ...). To compile follow the instructions in the README.

For authentication it is currently required to have an OpenID Connect provider. This can be Keycloak, for self hosting, or Google, OKTA, etc. Keycloak can be run in a docker container see https://www.keycloak.org/getting-started/getting-started-docker. Configuring Keycloak is out of scope, but isnt too hard: create a realm (kind of like an organizational unit) and add some users, then create a client “rdpgw” and obtain the credentials so can use them for configuring the RDP Gateway.

The configuration file for the Gateway is documented in de README. Make sure to set the random keys at the right locations. You can often generate these in a password generator. Add the servers you want to allow to connect to to the config file.

Thinking about it, you probably run into a bit of a challenge with the generated RDP file as you cannot specify the server you want to connect to. You can edit the RDP file to change that. This should be made easier. Note you only have limited time frame to do so for security reasons.

I hope this helps to get you started!

Cheers Bolke

thoj commented 3 years ago

About specifying host. I get these errors if i change the rdp file:

2021/05/18 09:30:26 Client specified host 172.16.4.11:3389 does not match token host any 2021/05/18 09:30:26 Not allowed to connect to 172.16.4.11:3389 by policy handler

I have "any" in hosts.

MaFreiberger commented 2 years ago

Yeah, a docu would be good. I wanted to use that project for it's purpose, but i think it's just not far enough and it's usecase too limited. No drop-in replacement for a MS-RD-GW, at least not till now.

ITGuyattheplace commented 1 year ago

I too am suuuuper keen to use this but it's too hard. I'm an admin of many years, well versed in a lot of technologies, but not a Linux neck-beard. Is there any way I can help to make installation easier?

bolkedebruin commented 1 year ago

If you could provide a kind of table of contents of what you would expect we could iterate over it and create the content together.

ITGuyattheplace commented 1 year ago

Yeah I can do that.

Firstly, a set of requirements and/or recommendations.

  1. Distro selection - Even a mention would be helpful for newbies
  2. Some clarification of Make and Go versions - I bumped into issues here, not sure if that was related to the above
  3. Any other required packages and at least a brief mention of any config that's not default

I didn't get much further than this in my first attempt. Essentially, give a newcomer an example of a working setup that can then be modified. From my experience, most of us admin types can fire up pretty much any box, isolate it via layer 2/3 networking and bump it along from there.

I'd be very happy to do some writing and screenshots etc, if you can help me through some of it.

bolkedebruin commented 1 year ago

Is there a reason why you would not use the docker version? That removes alle your issues basically and replaces it with "how to run this in docker".

ITGuyattheplace commented 1 year ago

Fair call. The use case I have in front of me, I'd rather not have a docker host in there as I'd have to run it as a VM. I'm not a huge fan of layering virtulisation but probably not the end of the world.

WayneArant commented 1 year ago

I am also very interested, and am using Docker, which I am fairly new to. I'd also like to see an installation guide of some sort, and would be willing to help.

I have gotten to the point where everything is running, but I get a failed redirect to keycloak. I suspect some of my issues are just lack of familiarity with the various technologies in play.

I did run into an issue with the Go version, but was able to get past it fairly easily. I'm considering spinning up a new OS instance and starting fresh so I can capture every step. I'm a Citrix guy by trade, so I'm hoping that helps with the concepts as I dig in...

One thing I would like (and maybe this would not be necessary for someone with more experience) is fuller descriptions of the options and the impacts each choice has in the configuration file. UPDATE: I was originally going to ask for ANY description, but I noticed that the readme file on this page has a YAML file with comments, those don't seem to be in the file that is generated in the build...

bmullan commented 7 months ago

@bolkedebruin

Is there a reason why you would not use the docker version? That removes alle your issues basically and replaces it with "how to run this in docker".

For me personally, I use LXD for both my "system" containers and for VMs because the LXD cmd syntax to create/start/stop/delete/clone is very similar for either. LXD also provides easy management of both local and remote LXD Containers & VMs note: "system" container = LXD runs a complete Distro (centos, debian, ubuntu, suse, alpine etc) with each container sharing the Host's Kernel.

Its easy enough to run a Docker container "nested" in an LXD container but I'd prefer not to incur that additional redundant overhead if possible

So I'd prefer to have a native installation method in addition to the docker approach.