LOL

They are trying to bore only your customers, attackers have direct access (=

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.

That has not been my experience… amdgpindriver was crashing quite often, gfx ring 0 timeout. Tons of people with that problem forums. I managed to adjust some parameters and fix it eventually.

VRR doesn’t work properly, I can get it to work, burnout is a shore every time.

I have both and nvidia and an amd GPU, and with xwayland fixed, the nvidia one can run just as well.

That said, paying 2k for a GPU to have raytracing and 24gb of RAM isn’t that attractive.

distcc so you can compile on the faster ones and distribute it