hckrnws
Note that `ssh git.charm.sh` is a serious privacy and security hazard: it will leak your local user name and the public keys for any keys you can authenticate with (enough to e.g. identify your GitHub account), and if you have ForwardAgent on (convenient but dangerous—if you use it, look into ProxyJump instead) it will allow the remote machine to impersonate you (e.g. push to any GitHub repository you can push to).
I recommend using an invocation like this instead when testing things like this; I think it’s enough (but welcome correction):
ssh -o PubkeyAuthentication=no -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -a nobody@git.charm.shMy public keys are public for a reason though.
I can’t imagine why you’d ever turn on ForwardAgent by default.
> My public keys are public for a reason though.
in the ideal, yes. but it wasn’t long ago (start of covid really) that i kept my personal and work ssh keys under the same profile. both of those alone are “public”, but that they correspond to the same identity perhaps ought not to be.
yeah, there are better ways to manage separate identities (separate users, VMs, VPNs)… and reminding people that `ssh host-name` can reveal all your ssh keys is a good way to push people toward those better solutions! :)
> reminding people that `ssh host-name` can reveal all your ssh keys is a good way to push people toward those better solutions!
I guess I just take issue with the fear mongering. People often make it sound like the end of the world to not be perfectly anonymous.
Is this the case with this config as well?
Host one
HostName one.of.the.server.sh
User hn
IdentityFile ~/.ssh/one.of.the.server.sh.key> My public keys are public for a reason though.
You may reasonably not care, but it’s also reasonable to care.
It’s not about them being public, it’s about announcing them. For me, running `ssh git.charm.sh` would have SSH essentially say “hi, I’m chris-morgan on GitHub (and here’s cryptographic proof)” as part of connecting. That’s a huge privacy leak. It’s disclosing all your identities automatically, including perhaps that you work for ACME Corporation, and isn’t that a valuable tid-bit for social engineering attacks, when you take all these things together.
(I think it’s worth noting of your pithy line that the two words spelled “public” are homonyms, not at all the same. The first one I might call cryptographic-public, and the second socially-public. There’s no need to share a (cryptographic-)public key (socially-)publicly, and doing so can be actively undesirable.)
As a matter of connecting it’s announcing that I’m user bart.riepe. It’s not a big leap from there to figuring out who I am.
A public key (to me) is public in the same sense that a client secret is public. You don’t have to advertise it to everyone, but if anybody finds it they can’t do anything bad with it (except confirm you are the person that has the private key).
This isn’t a technical security vulnerability, because the cryptography is sound.
But it is an information disclosure vulnerability, because it didn’t need to disclose your identity, and the typical user will not expect it to disclose all their identities.
And the information that is disclosed opens heavy social vulnerabilities, because your activity can now be perfectly correlated with who you are, by an untrusted party.
This is information that businesses put huge amounts of effort into attempting to do on the web, because it can be quite valuable (sometimes absurdly so). And SSH defaults to just giving them exactly what they want so they don’t even have to work for it.
Do you feel the same way about GitHub/GitLab... because Git works over SSH and anytime you clone anything over the SSH protocol your public keys are sent to the server. Same thing with SSHing into AWS, Google Cloud, Azure consoles. I don't think exposing your public key has ever been an issue for most people, and for those that it is, they can configure SSH access as you have in your parent comments.
That’s where you’re actually using it for authentication, for which there is obviously no alternative, and you also trust the party in question. The “demo over SSH” thing is not like that.
If you clone a public repo, this exact SSH flow happens on the GitHub servers, same with any other Git server running the SSH protocol. The OP is a git server just like that, so I don't see why it would be an issue here but not elsewhere.
I’ll put it this way.
When in a browser you connect to https://github.com, it sends your session cookie so the server knows who you are. Well and good. What it doesn’t do is send any of that to any other server; if example.com wants to know (and prove) your GitHub username, you have to go through an OAuth flow where you explicitly grant permission for sharing these details.
By contrast, the OpenSSH remote login client (`ssh`) defaults to leaking this potentially-sensitive information. It shares all your keys, when you probably actually want to share zero or one of them.
> It shares all your keys, when you probably actually want to share zero or one of them.
Is that true though? When I connect to a server I generally want ssh to connect with _any_ of the keys that are currently in my agent. For that to happen the server needs to check if I’m allowed to connect with each of them, therefore I have to send that information to the server.
I guess SSH could default to asking me which key I want to connect with and then store that info afterwards?
If I wanted it to connect using only a specific key for that host (or pattern), I’d specify that in my ssh config.
> I guess SSH could default to asking me which key I want to connect with and then store that info afterwards?
Exactly. When you consider that it already does this sort of thing for host keys, it’s really a pretty obvious way to plug the information disclosure vulnerability.
I'm talking about using Git over SSH (a protocol it and all of the Git hosts support). You can do this right now:
git clone git@github.com:Chanzhaoyu/chatgpt-web.git
And it will use SSH, no web browser involved: https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protoco...
Misconfiguration, or lack of understanding of what the agent does and how it works.
It's not always clear the inheritance priority of directives with wildcards in ssh_config or .ssh/config. I think it's the opposite of what one might assume is the default, if I recall correctly.
I’m not sure, connecting to an unknown server and giving that remote session the same abilities as my local PC has always seemed like a bad idea to me.
I guess you could misconfigure it, but it’s one of those things where I’d painstaking ensure I set it up correct because doing it wrong is not an option.
Maybe it’s because I almost always go direct?
[flagged]
The last part of your reply is extremely condescending and an absolutely unnecessary ad hominem attack.
People have been conscious about publishing their raw email address for ages be a use it attracts all kinds of bad actors, from spambots to outright scammers impersonating somebody else for social engineering. Publishing your social circle involuntarily can be something people actually do not want but are unaware that this is happening.
I think you may have misunderstood the privacy hazard I’m talking about. `ssh git.charm.sh` leaks your SSH identities, which is akin to announcing “Hi, I’m gauntletwizard on GitHub” (and quite possibly “I work for ACME Corporation”) by merely connecting, which is not something people are generally aware of or expect (that’s why I pointed it out). This allows for perfect tracking, and such tracking can easily support various nefarious actions. By contrast, HTTP only allows comparatively generic fingerprinting via things like your IP address and user agent characteristics, though certainly in some circumstances it can be possible to identify a user uniquely from these—but you’ll have to work at least a bit for it. More generally, over HTTP if someone wants to know that you’re gauntletwizard on GitHub, they’ll have to go via a GitHub OAuth flow, where you get told they want to know your account name, public email address, whatever, and you get to decide whether to allow this.
We've had to warn you before that personal attacks will get you banned here. Please don't do it again.
I love days like today, $SYSTEM goes down, then we get a thread about $ALTERNATIVES, and now posts about $ALTERNATIVE[X].
I like the look of this and the other stuff from the folks behind it, but I'm curious if anyone is using it "for real." I would love to use this over others with web UIs, but at this point I am also in the market for Git+Actions-analog, which Gitea and Drone (and now just Gitea) fill on their own. Am I missing the mark on this tool's use case, or is it not just to the place where it can do such things yet.
Soft-serve is not really an alternative to GitHub, unless you literally only use GitHub for the git functionality itself, but then you could just use any Linux server + openssh + git to get basically the same functionality. But I see people tend to use GitHub for much more than just Git, for better or worse.
If you actually want a github alternative, use gitlab. Can't speak to the web experience, but self hosted is miles better than any of the alternatives. I found gitea to be fairly lacking.
Now that more and more people are living as digital nomads, I just want a git server with S3 backend support so I can host it in the cloud.
I want to self-host, but I also don't want any infrastructure.
> I want to self-host, but I also don't want any infrastructure.
I think I understand what you're saying, but to me, "self host" means you are running your own servers. I.e. managing your infrastructure.
Maybe there needs to be some other term for "using the cloud, but only as dumb storage." Like cloud _storage_ vs cloud _app_...
Self-host is the right term. They install and host their OS or software themselves on a VPS, NOT a homeserver or VM. Until they set it up, there is no "cloud". "Cloud" IS a service, OS, etc that someone else set up and which you (pay to) use, and which that someone else ultimately has control over.
So this guy wants to run the software themself (the "self-host") without the infrastructure (the VPS which they rent yearly and which they have had to install Debian or Unbuntu 22, along with git and all the other software) - AWS replaces the infrastructure, and while it is close being "the cloud" it is still different because setting it all is still up to the user. They are still in control of their own data (although I guess some rogue AWS employee could read the data).
When I began reading this thread I thought roughly the same way. But not for long: if plugging together parts is building yourself a computer, then hosting on lower-level services is self-hosting.
But then on the other hand I'm on the "that's not self-hosting!" side when you shift from your own needs to selling a service: if you run and sell a gitsomething.com and it's all on AWS, that certainly isn't self-hosting. And again the similarity holds: when you operate a computer brand and it's all off the shelf parts you're not really a computer builder, even if the exact same configuration would nicely run under "I built this" when some by a consumer.
Yeah that used to be it for me too, until I got rid of all my possessions and started living more minimalistic.
Self-hosting is broad enough to include wanting to get away from large centralized vendors and take hosting into your own hands. Owning your domains and being vendor agnostic with IaC.
Check out rsync.net, it allows you to use git and ssh on its storage infrastructure. Create bare repos there and you can push/pull just like from github: https://blog.kozubik.com/john_kozubik/2010/02/git-and-subver...
You won't get any server side CI/hooks or even multi user management, but if you just want a central place to push and pull your private code it's perfect.
S3 sounds very inefficient for storing git objects. Unless you're talking converting git protocol to S3 Object Versions API which might sound like an interesting project.
I only say S3 because it's a cheap type of online storage that does not require any of your own infrastructure.
It's also a generic interface which is offered by multiple vendors (Azure, Backblaze, etc) including some on-prem options like MinIO.
I mean, on one level, a plain directory is also a generic interface, but blob storage has semantics which naturally lend themselves to replication in ways that a regular filesystem doesn't.
so you want to self host via the cloud?
... why not just use the cloud at that point and skip having to roll your own everything?
That's not SELF-hosting.
Self-hosting, with emphasis on the self, to me is taking it into your own hands.
Using the cloud can be very liberating these days, you can do it in a vendor agnostic way where you own all your domains, your data and can move freely between any cloud provider.
There's a sense in which using the cloud isn't SELF hosting either. Although I get what you mean.
It's even better than self-hosting on bare metal, because you can move from one vendor to another quicker using IaC.
Also more expensive of course.
To me self-hosting was always about freedom. The two arguments against self-hosting in the cloud are security and cost.
this is the play.
in the past have used git-remote-gcrypt[1] with rclone.
currently using git-remote-aws[2].
both work great.
Isn't it like putting your local repository on a dropbox or onedriver managed directory?
You're my friend, I'm just looking for the same!
Comment was deleted :(
The project has interesting approach to UI: differences between GUI and CUI (aka console user interface) are almost erased.
All of the https://charm.sh/ tools are beautiful like this. I've been looking for an opportunity to build on these, but haven't had a chance yet.
Those TUIs makes me want to learn Go..
(Does anyone know alternatives to this for nodejs though?)
The tech is not very specific to Go. I remember the library called Turbo Vision from Borland Inc. which gave similar console superpowers in the early 1990s. Internally it was not that different from a typical GUI toolkit - controls, modal windows, layout, but it worked exclusively for text mode.
Products based on that technology were quite impressive back in the day: Turbo Pascal 7.0, Turbo C. The only thing that I really missed back then was drag and drop (in console) and it's still an unachievium nowadays, afaik.
Modern Turbo Vision 2.0
If you are interested in comparing this offering to other existing tools, you may consider:
- gitolite https://gitolite.com/gitolite/overview.html , and
- cgit for http front-end https://git.zx2c4.com/cgit/about/
Isn't the easiest self hostable git server just another copy of the repo in a different location?
I tried to use it, but my git repo was too big and it become painfully slow. I filed a bug an the issue was fixed within a few weeks. Very good interaction with the developers!
However that also meant that I needed an alternative. So let's break down what soft-serve do: 1. It's a ssh server/git server 2. It can list git repositories 3. It can browse git repositories
For: 1. you can use your current ssh server and for extra protection use the git-shell that comes with git. 2. Is easily solved with git-shell-commands (see man git-shell) 3. Is not something I need. If you want to browse you'll need to clone.
Although soft-serve is beautiful, it's a lot of added complexity for not very much functionality. If/when they add CI/CD, pull requests (perhaps a git-appraise based interface). It will be awesome and I'll give it a new try.
This is all uinclear to me.
--> pacman -S ssh git
Voilà, you're self hosting a git server...
Now manage users and granular user-level access to repos... it's doable but you're going to write a boatload of one-off scripts and hacks, which tools like soft-serve have already implemented.
pacman -S gitolite
Yes or just install soft-serve, another git server implementation (with much more sane documentation IMHO, gitolite is great but the docs are a scatterbrained mess).
The point is that a git server isn't just ssh and git except in the most barebones simple use case.
Right, but you could easily end up writing a bunch of custom automation scripts and/or APIs around this, at which point (unless you really like DIYing stuff) you might better off with something like Soft-serve.
Slightly OT: how feasible is it to do issue management as markdown within a monorepo, anyone have any experience with this? Fossil does this already, but I think git could do it just as well?
Git-bug: Distributed, offline-first bug tracker embedded in Git
I wish that this TUI could integrate directly with gitea or gitlab and wouldn't be a standalone server.
I'm very curious what their business strategy is.
Their website implies that they are available for hire for enterprise consulting.
That looks awesome for RPI home server.
I almost want to try this but I think github does a better job of keeping my data safely hosted than I would.
Hmm I'm sold on git over https. One of many things that forgejo has right.
Still using gitosis, and still happy with it.
Crafted by Rajat
Source Code