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.
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.
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.)