This would only work if there is no other traffic on the port being used (eg: port 22). If both the host SSH service and Forgejo SSH service expect traffic on port 22, then this would not work since server name indication (SNI) is not provided with SSH traffic and Caddy would not be able to identify the appropriate destination for multiple SSH services traffic.
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
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.
I dont know about caddy but nginx proxy manager does this very well. Also, if running in docker, you can expose the port that runs ssh for forgejo und a different port than the host machine‘s (eg 2222). In that case you just put the remote in with the port and call it a day.
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.
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.
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
Are you able to provide some details on how you are doing this? I don't think you can do much with reverse proxies and SSH beyond routing all traffic on port 22 (or the configured SSH port) to whichever port SSH is listening on. In other words, the reverse proxy cannot route SSH traffic for the host on port 22 to the host, route SSH traffic for Forgejo on port 22 to Forgejo's SSH process, and SFTP traffic on port 22 to the SFTP process - at least not via domain name like a HTTP/HTTPS reverse proxy would work.
Instead, this would need to be done via IP address where the host SSH process listens on 192.168.1.2, the Forgejo SSH process listens on 192.168.1.3, and the SFTP process listens on 192.168.4. Otherwise, each of those services would need to use different ports.
I believe the reverse proxy settings in your post is just configured to handle the http/https connection, not the SSH connection. Instead, SSH connections are likely being routed to the machine running Foegejo via DNS and your reverse proxy is not involved with anything related to SSH.
I assume you either have SSH disabled on your host or SSH on your host uses a port other than 22?
It works but I don't think Forgejo plans to support it in the future. Gitea and Forgejo started to diverge and the documentation regarding docker is somewhat in a deprecated state.
Edit: I also think the OP's question is different from this. So this might not be a solution.
I solved this by setting my changing a setting somewhere in forgejo to display the ssh url as something like ssh.mydomain.com so that I could keep my forgejo domain pointed to the reverse proxy but point git.mydomain.com to the forgejo container which has its own ip address. This is all for local traffic. For other traffic both domains point to my routers ip and I forward port 22 to the forgejo container.
Because forgejo's ssh isn't for a normal ssh service, but rather so that users can access git over ssh.
Now technically, a bastion should work, but it's not really what people want when they are trying to set up git over ssh. Since git/ssh is a service, rather than an administrative tool, why shouldn't it be configured within the other tools used for exposes services? (Reverse proxy/caddy).
And in addition to that, people most probably want git/ssh to be available publicly, which a bastion host doesn't do.
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.
If you connect from outside your LAN, you would need to forward the ssh port to the server in your router settings.
If you are inside the LAN, just use the ip address of the forgejo server.