Live data from Hacker News

How Git servers work, and how to keep yours secure

gemini.nytpu.com

41–50 of 51 posts

Re: How Git servers work, and how to keep yours secure

#41
post #38

For those trying to host a git server on your home network like I have and encountered network issues even after port forwarding, you might be behind carrier grade NAT. You'll need some forwarding solution, or use an SSH reverse tunnel to punch through CGNat. Use something like ngrok or localhost.run. For example if you're using gitea, host it on localhost:8080 then run this: ssh -R 80:localhost:8080 localhost.run Th…

How could one selfhost localhost.run setup on own wildcard domaine?

If you're talking about,

> alternatively host your own reverse SSH tunnel on a VPS somewhere.

To make a quick version, on a VPS or somewhere, install OpenSSH server. Modify your sshd.conf file adding,

    GatewayPorts yes
Then you can use something like this,

    ssh -R 8080:localhost:22 user@server.example.com
After that, you can use,

    ssh user@server.example.com -p 8080
from any other computer and it will connect you to the machine you ran the ssh -R from.

Re: How Git servers work, and how to keep yours secure

#42

For those trying to host a git server on your home network like I have and encountered network issues even after port forwarding, you might be behind carrier grade NAT. You'll need some forwarding solution, or use an SSH reverse tunnel to punch through CGNat. Use something like ngrok or localhost.run. For example if you're using gitea, host it on localhost:8080 then run this: ssh -R 80:localhost:8080 localhost.run Th…

In addition to this:

Carrier grade NAT ISPs sometimes have global scope ipv6s assigned, and if the other endpoint has ipv6 support, too, you can breakout easily using the assigned ipv6.

Rather than that I would recommend reading up on DNS exfiltration techniques [1] and things like pwnat [2] that use faked SNMP reply packets that make routers think they forgot to let a data packet through for hop traces.

And if you have the time, I'd recommend to use websockets as a tunneling protocol because it's very flexible in its payload size and allows compressions via websocket extensions and the srv flags. I wrote a detailed article that explains the WS13 protocol and all its quirks [3]

Additionally to that it's good to know the limitations of a SOCKS proxy, hence that's what most "easy to use" implementations provide. Spoiler: forget ipv6 via socks5 proxies. I also wrote a detailed article about its quirks [4]

I'm currently experimenting with the idea of a DNS protocol implementation that uses multicast DNS service discovery to find local peers and that uses DNS exfiltration techniques to breakout of a CGNAT, but I'm not there yet to write a detailed article about it. It's current research for my stealth browser project.

[1] https://blogs.akamai.com/2017/09/introduction-to-dns-data-ex...

[2] https://github.com/samyk/pwnat

[3] https://cookie.engineer/weblog/articles/implementers-guide-t...

[4] https://cookie.engineer/weblog/articles/implementers-guide-t...

Re: How Git servers work, and how to keep yours secure

#43
post #27

Earlier quoted context omitted.

Is there any reason your example would ever happen? That seems a little far fetched of a security concern to me.

It absolutely happens for some organizations. There's industries around it. And anyway, seems like good practice, and shouldn't be hard to do, and should fit with workflows already familiar from work. What would be bad practice is to give less-trusted devices (e.g., Linux development phones, or some disposable PC on which I had to install some sketchy software) access to all my files and backups. Using git this way m…

Gitolite/gogs/gitea should all be capable to enforce policies like what you described.

If your concern is data loss/malware, anything on the git level is going to be insufficient (but can still be useful of course, as you said)

I’d echo the suggestion of zfs snapshots replicated on a separate mirror of disks. I can recommend zrepl to set up the snapshotting/replication/pruning part. Syncoid is another popular one.

Re: How Git servers work, and how to keep yours secure

#44
post #10

Is there a rock-solid git server that I can use on a home server for versioned immutable backups of misc. files on personal devices (e.g., account config), as well as private software development git repos? (I've done a cheaper version of this -- except for the immutable part, and the separation of accounts between devices -- in the past using SSH+SVN to a home server, and it was great.) I was thinking immutable from…

Is there a reason you can’t continue to use Subversion for this? Sounds like its feature set (immutable commits) is closer to your requirements? Subversion still exists and is still easy to set up on a home server. (It’s what I still use for this purpose, even in 2021.)

Re: How Git servers work, and how to keep yours secure

#45
post #28

I like self hosting git but these tutorials set you up with only a one-machine solution. I'd like to be able to self-host a git service that's robust in the face of network/hardware/OS maintenance. I know git is distributed by design. So if I want to push code to a pair of servers for better availability, I can do it explicitly: git push git push But what if I wanted to make this transparent but still highly availabl…

Plenty of alternative approaches that can get you there. Here’s one: * distributed file system like gluster or ceph for repos * clustered db (eg replicated Postgres) * redundant instances of gitea * load balancing Am I missing something?

post-receive hook pushing everything to other instances. How the push happens could be git remotes, rsync, or whatever else you want.

Re: How Git servers work, and how to keep yours secure

#46

I like self hosting git but these tutorials set you up with only a one-machine solution. I'd like to be able to self-host a git service that's robust in the face of network/hardware/OS maintenance. I know git is distributed by design. So if I want to push code to a pair of servers for better availability, I can do it explicitly: git push git push But what if I wanted to make this transparent but still highly availabl…

I push to a couple places that have a main git server that everyone pushes to/through and then that somehow pushes everywhere else.

post-receive hook[1] can be used to automate that,

[1] https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks#_po...

Re: How Git servers work, and how to keep yours secure

#47
post #23

What would be the best practice way of allowing git pushes similar to how heroku handles them? I'm wanting to implement a feature that allows users to push to deploy new themes.

Push to an intermediary location. Use post-receive hook to trigger whatever actions you need. At the end, push that to the server and reload whatever you need.

https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks#_po...

Re: How Git servers work, and how to keep yours secure

#48
post #22

Earlier quoted context omitted.

Why? (Asking as someone running Arch on many servers for the last 5 years, and debian server for much longer) I can think of a few things I dislike, but all of the failures so far were self-inflicted. Like forgetting to update packages that I self compiled outside of supported repository. It's not completely autonomous when it comes to upgrades, you have to think for a while before hitting "yes" after seeing the list…

Arch changes too much, and change means risk. In my opinion, for production, boring is always best. If the latest flavor of X is absolutely essential for the business, there are typically ways to get it for most LTS distros (back ports, third part repos, etc).

It also changes in ways that can make it hard to automate deployments. For instance, the base package group used to include a kernel, but no longer does.

Re: How Git servers work, and how to keep yours secure

#49

For those trying to host a git server on your home network like I have and encountered network issues even after port forwarding, you might be behind carrier grade NAT. You'll need some forwarding solution, or use an SSH reverse tunnel to punch through CGNat. Use something like ngrok or localhost.run. For example if you're using gitea, host it on localhost:8080 then run this: ssh -R 80:localhost:8080 localhost.run Th…

In addition to this: Carrier grade NAT ISPs sometimes have global scope ipv6s assigned, and if the other endpoint has ipv6 support, too, you can breakout easily using the assigned ipv6. Rather than that I would recommend reading up on DNS exfiltration techniques [1] and things like pwnat [2] that use faked SNMP reply packets that make routers think they forgot to let a data packet through for hop traces. And if you h…

Please excuse the offtipic here, but I found no other way of contacting you - how did U manage to put 32gb ram in your T440P your're pointing out in that old post of yours?|

" Using a t440p base as my laptop, best laptop for the buck. bought it as a 4300m model with a dual core. now it has an IPS display, better coreboot+bios update, 32gb ram, i7-4712, 2x 512gb ssds plus a 4tb hdd. all together cost me less than 600eur. hackintosh compatible if necessary, though it's running Arch these days. "

If it's via modded coreboot revision, please do mail me the file when possible @: delio_man@abv.bg

10x in advance and sorry 'bout the Spam!

Re: How Git servers work, and how to keep yours secure

#50
post #16

Earlier quoted context omitted.

"Is there a rock-solid git server that I can use on a home server for versioned immutable backups ..." A few things ... First, 'git' is built into the rsync.net platform and you can do anything you like with it, remotely, over ssh: ssh user@rsync.net "git clone git://github.com/freebsd/freebsd.git freebsd" I personally track a number of repos I consider important and keep my own source trees up to date without runnin…

A question I had for a long time: is rsync.net affiliated in some way with the authors of the rsync utility?

No, there is no affiliation at all.

However, in late 2005 / early 2006, when we spun it out[1] as a standalone corporation and registered the domain name, etc., I did request, and receive, explicit permission from the authors/maintainers of rsync to adopt, and use, the rsync.net name.

[1] rsync.net began operation in 2001 as an add-on feature to JohnCompanies which was the first provider of the VPS as we now know it.

Post reply on HN