That's a neat idea, but I would try to simplify it a bit. Now, the details are fuzzy as I haven't set up anything like this but I know the theory behind it.
You could setup a website which accepts file uploads at username:file_signature@example.com , when a request is accepted you retrieve the public ssh key for "username" and validate that the "file_signature" is valid for the file uploaded.
The point of including GitHub in the chain is that it's acting as an SSO provider, thus:
1. letting you ban bad actors from your system by creating a blacklist of GitHub usernames; and
2. putting a stumbling block in the way of getting around #1 by signing up for 1000 accounts (signing up for a GitHub account takes a while; adding a unique new SSH key[1] to that GitHub account means generating a new SSH keypair, which takes another while; etc. Having a GitHub account with an associated SSH key constitutes a very small proof-of-work, similar to an e-stamp.)
[1] IIRC, a given SSH public key cannot be associated with more than one GitHub account at a time.
Any SSO provider would provide the same guarantees; but GitHub is the only SSO provider that has people's SSH pubkeys on file and accessible through a public API, and so GitHub is the only SSO provider you can use as an SSO provider through SSH.
Also, as a separate "benefit" (though some would argue it's the opposite), GitHub accounts — SSO accounts generally — are more-often-than-not associated with people's personal identities. SSO identity-provider sign-up processes usually collect quite a bit of PII, and often do a bit of KYC with phone verification, etc. This means that requiring sign-in through SSO is an almost-perfect ward against criminal use of your service — since any criminal stupid enough to SSO into your site and then do something illegal, can be quickly-and-easily identified by the police by sending a warrant to the SSO provider.
-----
Besides all that, the point here is to make the process of uploading a file as simple as possible for the end-user (presuming the end-user is a developer familiar with common CLI tools.) The backend complexity isn't really a concern, if it presents a simple and straightforward API.
With GitHub-identity-supported SSH-pubkey-auth, anyone who has a default SSH keypair and a GitHub account (and who has registered their default SSH keypair against their GitHub account) can directly jump to typing `scp ./file mygithubuser@uploader.example.com:` and it'll "just work" — without having to ever even visit uploader.example.com to register an account! Most developers have a GitHub; and most developers have used SCP before at some point. It's a very familiar process. Less confusing, even, than GitHub's own requirement of needing to SSH into github.com as the "git" user.
With your scheme, meanwhile, the user has to figure out how to sign a file using SSH — something I don't think more than a handful of people in the world will have ever had previous experience with. That's not quite "easy" on the level of "just use cURL" or "just use SCP" :)
You could setup a website which accepts file uploads at username:file_signature@example.com , when a request is accepted you retrieve the public ssh key for "username" and validate that the "file_signature" is valid for the file uploaded.
It's a bit unintuitive to sign files with your SSH key but possible https://superuser.com/a/1616656/51984