Link SSH fingerprints to Git Proxy users

[coopernetes]

A follow-on from #1604, use SCM's well known endpoint to view a given user's SSH key fingerprints, list key fingerprints of all known SCM users that GitProxy is aware of (it was gitAccount but that field is likely to be reworked and revisited as per @kriswest comment below) and carry that link of GitProxy-user-to-SCM-user internally for SSH pushes.

Why this is important?

SSH support today trusts a set of registered public keys, but the association between a key and an SCM identity is self-asserted and unverified. Any authorization decision rests on a key->identity link that may be wrong. For example:

• Alice has a git-proxy account and her own SSH key bar (she legitimately holds the private key). The key grants some permission to an upstream like github.com/baz/repo.
• Nothing today stops bar from being linked to thomascooper-github - the GitProxy user -> SCM user mapping is asserted, not checked against the SCM.
• Alice's pushes are then linked to, and authorized as, Thomas.
• Building the link from the SCM's published keys closes this: bar is not among the keys published under thomascooper-github, so the association is rejected. A user can only be linked to an SCM identity whose published keys include the key they're connecting with.

This would be the SSH counterpart to the token (HTTP Authorization header) -> user linkage in #1604.

This allows for GitProxy to associate a key with a known SCM identity in addition to the GitProxy internal user registration of SSH public keys. Both GitHub and GitLab expose unauthenticated endpoints to do this lookup for a given public user.

$ curl https://api.github.com/users/coopernetes/keys
[
  {
    "id": 90942779,
    "key": "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIKz6e608fCNeq1/Qi3NRacRm44ax05XhVNeahiRi9/HE",
    "created_at": "2023-11-22T02:38:13Z",
    "last_used": "2026-07-15T03:58:16Z"
  }
]

Note, I discovered that Forgejo & Gitea instances do not provide this endpoint without authentication. Either an OAuth app or a GitProxy owned token is required to hit the equivalent API for that SCM provider.

[fabiovincenzi]

The gap you describe is real. SSH auth today just looks the key up in the database, and users register their own keys, so nothing checks that a key really belongs to the gitAccount they claim. Good catch on Gitea and Forgejo needing auth for this, too.

Two questions before we build it, and one observation.

Is this really as strong as the PAT check?

I don't think it can be, and the reason is that a PAT is a secret, a public key isn't.

With a PAT, handing it over already proves you own it, and GET /user tells us who you are.

With GET /users/<login>/keys, all we learn is that a key is published on someone's account. We don't learn that the person connecting to us actually holds it. Anyone can download that list. It doesn't prove anything about who is on the other end of the connection.

There's also a practical side to this. The upstream already does this check for us, on every push. We use agent forwarding, so the push is signed by the client's own agent, and GitHub verifies that signature itself. Someone who presents a key they don't hold still can't push as its owner.

So I'm not sure the lookup would stop anything the upstream doesn't already stop.

What would use the result?

Right now, on the SSH path, gitAccount doesn't affect any decision:

• findUserByGitAccount is only called from resolveUserFromToken
• that step returns early for SSH, because req.user is already set
• the gitAccount we put into authContext is never read anywhere

So if we added this check today, it would log a warning about a field nothing consults. But I might be missing a planned consumer.

One more thing: That agent signing above may already give us a stronger signal, for free.

The way ssh2 drives publickey auth, the agent is only asked to sign after the server has accepted the key. So the key used in the successful attempt is one the upstream both recognised and verified for us.

Happy to pick this up. Mostly I'd like to agree on what consumes the result before writing any code.

[kriswest]

Hi @coopernetes - we discussed this issue at #1672 - I'm a little confused by it.

Why this is important? Today, SSH support works on a set of known trusted public keys from users. However, there is no way to definitively determine that a given SSH key belongs to a known identity.

In my view, the most reliable method of determining whether the public key belongs to a particular entity is their ability to use it - i.e. because they hold the private key. Without the private key the public key isn't usable and cases where the user posts a public key that is not their own do not give them any additional access to anything - rather they are giving access to the holder of the private key. If we base validation on anything other than the presence/ability to use the private key I worry that weaken security as (for example) a user could deliberately post a public key in github, which we then validate against without out truly confirming ownership of the private key. I think in practice the private key is still required, but it still feels off to me.

Hence, I'm not convinced we need to validate public keys against the upstream, as proxying requests will simply fail if the public key is not available at the remote end... hence, there may not be any need to add complexity (and venue specific complexity) to the application for validation.

We also noted a slight conflict with @andypols' changes relating to gitAccount in that he's removed it from the UI for the time being. We're expecting to come back with new support for setting usernames (and other other necessary credentials) on a per-venue basis shortly.