I use boring proxy for a lot of self-hosted services and really like it. As an admin I want to use boring proxy to create temporary tunnels for SSH access to the machine where other services are hosted.
I tried all permutations but could not figure out how to forward the SSH port.
Could anyone please provide an example of how to connect to a SSH server? Thanks!
I know, that feature requests would be best placed on GitHub but it would be awesome to have separate tokens that would allow access to the boring proxy ui to just enable or disable a tunnel. Maybe even time based for one hour. That way, boring proxy could emulate Just-In-Time access as it gets used by cloud providers to tighten security.
Hey @reiro. boringproxy doesn’t currently support reverse-SSH connections. The main reason for this is because all routing is based off the host name from the TLS client hello, ie only TLS-based connections are supported. Since SSH uses it’s own encryption stack it won’t work. It might be possible to add this functionality, but it’s not something I need personally so probably wouldn’t happen for a while. I’d recommend checking some of the other tunneling options from my list:
You may be able to use one of those instead of boringproxy, or even alongside it.
It’s fine to ask for features on the forums. As far as disabling tunnels go, can you provide a real-world use case for this? Personally I just delete/add tunnels as necessary.
Thanks! That explains a lot
As a workaround I could use something like Shellinabox.
Regarding the disabling of tunnels:
The main real-world usecase would be Just-In-Time access:
Just-in-Time (JIT) access is a fundamental security practice where the privilege granted to access applications or systems is limited to predetermined periods of time, on an as-needed basis. This helps to minimize the risk of standing privileges that attackers or malicious insiders can readily exploit.
So I actually got to looking into reverse SSH a bit, and it might not be that hard to add to boringproxy. Adding raw TCP tunnels (including SSH) would be a useful feature. I’m going to see if I can hack this together soon and I’ll report back here how that goes.
As far as JIT access, the existence of such a feature makes sense, but I don’t think it’s a good fit for boringproxy, at least for now. It seems more useful in an enterprise setting, whereas boringproxy is focused on self-hosting.
That said, you might be able to implement something like this yourself by making a small webserver that simply accepts two requests: /on and /off (perhaps with a minimal HTML UI). /on would use the boringproxy API to create a specific tunnel. /off would delete it. You could then run this server behind boringproxy with a username and password. Then anyone with the credentials could access those functions, but that would be the only privileges they have. It’s hacky but should work.
Well that didn’t take very long. Turns out boringproxy already supports reverse SSH if you use the correct incantation. Definitely need to streamline this a bit and document it, but I just tested it and it worked.
Say your boringproxy server is running at example.com and you want to be able to do ssh -p 8022 example.com in order to ssh into a specific client.
Here’s the steps:
Create a tunnel with the following values:
Tunnel Port: 8022
Client Name: whatever client you want to ssh into
TLS Termination: Server
Client Port: 22 or whatever the client machine is running sshd on
Allow External: TCP true
That should do it. You’ll need to make sure port 8022 is open on the server. You can use whatever port you want, just make sure it’s open and matches what you use when you try to connect ssh.
Note: The key was setting TLS Termination to Server, because that opens up the code path for the client to support raw TCP connections. I need to change this to be a setting on the tunnel itself, so it will work with server or client termination. Or maybe add an option to disable TLS altogether for SSH tunnels since the domain and TLS will never be used.
EDIT: For anyone looking at this later, make sure you also have GatewayPorts clientspecified in your sshd_config file on the boringproxy server machine.
How did you manage to get the tunnelled SSH connection working? I added a new tunnel as @anders suggested and it is listening on port 8022. However, it is listening on localhost (127.0.0.1) and not on 0.0.0.0.
Did you make another change to allow routing of external traffic to localhost? As far as I know allowing the port through the firewall will only open the port if its already listening on local address 0.0.0.0:8022. Its possible to route 0.0.0. traffic to 127.0.0.1, but I don’t want to allow that system wide; or are all your BoringProxy ports listening on 0.0.0.0?
Do you have GatewayPorts set correctly in your sshd_config on the boringproxy server machine? The instructions are buried at the bottom of the installation page:
I hope it’s appropriate to dredge this thread back up a year later; I’m not able to SSH to my client. I have the following proxy settings:
Domain: ssh.mydomain.com
Tunnel Port: 8000
Client Name: the client’s name
Client Address: 127.0.0.1
Client Port: the client’s SSH port, which is open with sudo ufw allow ssh
TLS Termination: I’ve tried Client raw TLS and Server raw TLS
Allow External TCP: I’ve tried with and without this
The furthest I’ve gotten is running:
ssh root@ssh.mydomain.com
which logs into the proxy server, not the client; I haven’t found a combination that lets me SSH into the client.
GatewayPorts clientspecified is set on the boringproxy server.
Any ideas what I may be doing wrong? I have multiple tunnels working to things like Nextcloud, Gitea (with SSH for pushing and pulling), etc., SSH to the client is the last obstacle.
@joshuao sorry for the late response but glad you got something working. frp is an excellent project and highly recommend it for anyone looking for a production-quality solution.
For reference, in your boringproxy example you would need to specify the port when running the client ssh command, ie
ssh -p 8000 root@ssh.mydomain.com
You also don’t need to open any ports on the client, but you do need port 8000 open on the server. Also, Server HTTPS is definitely the TLS termination option you want.
I tried again, specifying the port in the ssh command as you described (and properly opening port 8000, which I did when setting up frp but I bet I didn’t do before), and it now works. Thank you so much!
