3 ms·

Tangentially related: when I run Gitea on a LAN server under a Tailscale hostname, and i have Tailscale SSH enabled, do I have to use Gitea's built-in SSH serve

Tangentially related: when I run Gitea on a LAN server under a Tailscale hostname, and i have Tailscale SSH enabled, do I have to use Gitea's built-in SSH server with a custom port? When I try using port 22, even with PAM on (as requested by Gitea), sshing to gitea@hostname asks for my tailscale login then gives me a shell session (causing git push to fail). https://tailscale.com/kb/1193/tailscale-ssh/#advertise-ssh-on-the-host https://tailscale.com/kb/1193/tailscale-ssh/#advertise-ssh-o... says tailscale ssh "configures tailscaled to intercept all traffic from your tailnet that is routed to port 22 on the Tailscale IP address". I suppose I could set an ACL to only make Tailscale SSH intercept logins to nyanpasu64, and not other users like root or gitea (I haven't tested if Tailscale will reject other users or passthrough to gitea). I'm not sure if I should only approve my account, all nonroot, or "all but root and gitea" (unsure if possible with current syntax).

Joel_Mckay 4y ago
If I recall Gitea can run its owns libssh instance on a different port, and requires manually importing keys for each user. If you are using the https interface by default, than one may need to explicitly use the ssh:// uri. Gitea should not be exposed to the web, and a port knock sequence is highly recommended to keep private projects private. ;)
- nyanpasu64 4y ago
  I'm running Gitea in my LAN only, and currently hiding behind Tailscale (only listening to the Tailscale IP for HTTP, forgot to set that up for SSH over a custom port but that's not really a vulnerability) rather than exposed to other LAN devices. I may open it up to my full LAN in the future, I haven't decided.
  - Joel_Mckay 4y ago
    Another issue with Gitea we found was memory requirements are somewhat unclear. So if you have to version large binary images in a source tree, the daemon can develop a number of hard to diagnose failure modes. It may sound ridiculous, but make sure you have at least 4GiB of free ram. Most of the time it will never be used, but it is far better than chasing ghost issue for that edge case where it does. ;)

Joel_Mckay 4y ago

If I recall Gitea can run its owns libssh instance on a different port, and requires manually importing keys for each user. If you are using the https interface by default, than one may need to explicitly use the ssh:// uri. Gitea should not be exposed to the web, and a port knock sequence is highly recommended to keep private projects private. ;)

nyanpasu64 4y ago
I'm running Gitea in my LAN only, and currently hiding behind Tailscale (only listening to the Tailscale IP for HTTP, forgot to set that up for SSH over a custom port but that's not really a vulnerability) rather than exposed to other LAN devices. I may open it up to my full LAN in the future, I haven't decided.
- Joel_Mckay 4y ago
  Another issue with Gitea we found was memory requirements are somewhat unclear. So if you have to version large binary images in a source tree, the daemon can develop a number of hard to diagnose failure modes. It may sound ridiculous, but make sure you have at least 4GiB of free ram. Most of the time it will never be used, but it is far better than chasing ghost issue for that edge case where it does. ;)