A follow-on from #1604, use SCM's well known endpoint to view a given user's SSH key fingerprints. GitProxy can then correlate an incoming SSH key to link it back to a user known within the system.
This allows for a similarly strong identity linkage between a given SSH public key received by GitProxy's SSH agent and the upstream user that exists on an SCM. 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.
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. Using this API in a "reverse" direction compared to HTTPS PATs, GitProxy can query the list of known users (the gitAccount today) and correlate a given public key's fingerprint to ensure it matches a known upstream SCM account name.
See references below:
RBC/fogwall#380
RBC/fogwall@93b1f12#diff-5dd2e378bfaa5f3cae0e8250092002dd9141829b0454b83642baf68984468410R25-R29
A follow-on from #1604, use SCM's well known endpoint to view a given user's SSH key fingerprints. GitProxy can then correlate an incoming SSH key to link it back to a user known within the system.
This allows for a similarly strong identity linkage between a given SSH public key received by GitProxy's SSH agent and the upstream user that exists on an SCM. Both GitHub and GitLab expose unauthenticated endpoints to do this lookup for a given public user.
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.
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. Using this API in a "reverse" direction compared to HTTPS PATs, GitProxy can query the list of known users (the
gitAccounttoday) and correlate a given public key's fingerprint to ensure it matches a known upstream SCM account name.See references below:
RBC/fogwall#380
RBC/fogwall@93b1f12#diff-5dd2e378bfaa5f3cae0e8250092002dd9141829b0454b83642baf68984468410R25-R29