Hi, how do you run forgejo under a reverse proxy while using an ssh channel to pull/push commits?

From what I understand caddy is only able to proxy http traffic.

2 points

There’s really no need to reverse proxy ssh. What are you attempting to accomplish with the reverse proxy exactly? Http proxying allows you to add things like TLS encryption and modify headers. But ssh is a secure protocol already and you can’t really modify much in transit.

permalink
report
reply
1 point

There are plenty of valid reasons to want to use a reverse proxy for SSH:

  • Maybe there is a Forgejo instance and Gitea instance running on the same server.
  • Maybe there is a Prod Forgejo instance and Dev Forgejo instance running on the same server.
  • Maybe both Forgejo and an SFTP are running on the same server.
  • Maybe Forgejo is running in a cluster like Docker Swarm or Kubernetes
  • Maybe there is a desire to have Caddy act as a bastion host due to an inability to run a true bastion host for SSH or reduce maintenance of managing yet another service/server in addition to Caddy

Regardless of the reason, your last point is valid and the real issue here. I do not think it is possible for Caddy to reverse proxy SSH traffic - at least not without additional software (either on the client, server, or both) or some overly complicated (and likely less secure) setup. This may be possible if TCP traffic included SNI information, but unfortunately it does not.

permalink
report
parent
reply
1 point
*

There are a few ways to do it, but you don’t use caddy for SSH.

  • host SSH on port 22, forgejo on a different port. Expose both ports to the internet
  • host SSH on a different port, forgejo on port 22. Expose both ports to the internet
  • host SSH on port 22. Forgejo on port 2222. Only 22 exposed to the internet. Change the authorized_keys user of the git user on host to automatically call the internal forgejo SSH app

Last option is how I run my Gitea instance, authorized keys is managed by gitea so you don’t really need to do anything high maintenance.

~git/.ssh/authorized_keys:

command="/usr/local/bin/gitea --config=/data/gitea/conf/app.ini serv key-9",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,no-user-rc,restrict ssh-rsa PUBLICKEYHASH

/usr/local/bin/gitea:

ssh -p 2222 -o StrictHostKeyChecking=no git@127.0.0.14 "SSH_ORIGINAL_COMMAND=\"$SSH_ORIGINAL_COMMAND\" $0 $@"

127.0.0.14 is the local git docker access where I expose the service, but you couldn’t different ports, IPS, etc.

permalink
report
reply
2 points

Learn NGINX that is the only answer, it’s a B!+€# to get configured but once you know how it will save you so much time, If you want cheat mode run the docker image and use the web interface but make sure to rtfm there are some gotch ya’s

permalink
report
reply
2 points

Use something that can do TCP, i.e. HAProxy, NGINX or Apache

permalink
report
reply
4 points

Not really through Caddy but for my setup I have it so the ssh port for Forgejo is only accessible through tailscale. So for push/pulling updated my ssh config file to something like

Host git.mysite.com HostName tailscaleMachineName User git Port 1234

Then doing git pull git@git.mysite.com:user/project.git works just fine as long as I am connected to tailscale

Otherwise you could open the port for Forgejo’s ssh so that you can access it without any vpn

permalink
report
reply
2 points

I feel silly for not realizing that the SSH config would be used by Git!

I thought if Forgejo’s SSH service listened to a non-standard port that you would have to do commands with the port in the command similar to below (following your example). I guess I assumed Git did not directly use the client’s SSH service.

git pull git@git.mysite.com:1234:user/project.git
permalink
report
parent
reply
2 points

Ahh, thank you! I’ve been banging my head against a wall trying to figure out how to do this.

permalink
report
parent
reply

Selfhosted

!selfhosted@lemmy.world

Create post

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don’t control.

Rules:

  1. Be civil: we’re here to support and learn from one another. Insults won’t be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it’s not obvious why your post topic revolves around selfhosting, please include details to make it clear.

  4. Don’t duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

Community stats

  • 5.2K

    Monthly active users

  • 1.8K

    Posts

  • 19K

    Comments