This is incompatible with using curl as your client, but one “hacker-friendly way to do auth” is to use Github’s public SSH keys API.
You can stand up an (SCP/SFTP-subprotocol-only) SSH server, and tell the user to log in with their GitHub username + GitHub SSH key. Then configure your SSH server to call[1] a check on GitHub’s API to map the provided username to the GitHub user’s set of public SSH keys. From there, the server treats that list exactly as if it were the user’s ~/.ssh/authorized_keys file.
Following that, you can configure PAM to continue the auth process however you like, policy-wise: let any GitHub user in; only let GitHub users in from a specific GitHub org; keep an LDAP directory of GitHub usernames such that you can attach metadata to them like “is banned” or “has used up their upload credits for the day” or “is on plan tier X”; etc.
Then, to actually handle the uploads, you can 1. set up automatic local user instantiation per remote user; 2. populate /etc/skel with just the right set of limited files to allow the user to upload into one “spool” directory; 3. have an inotify-like daemon that watches for files to be closed in that directory and handles them from there (e.g. uploading them to an S3 bucket, etc.)
—————
Or, alternately, you can avoid building this on top of OpenSSH, since you’re really fighting against the current by trying to virtualize everything, when OpenSSH expects to be relying on, and providing access to, a traditional POSIX environment.
Instead, you can have your own SSH server daemon that provides access to a pretend environment inside the SSH-server process, and handles SCP/SFTP upload streams through a custom in-process handler, the same way a web framework handles PUT requests.
I don’t know how common this is in other runtimes, but Erlang has an SSH server framework that you can use to implement exactly this. (As it happens, I’ve also written a high-level service that uses this SSH server framework to implement an alternative carrier for Erlang remote shell, where you can just SSH into the Erlang node to get a shell on it: https://github.com/tsutsu/exuvia. This app is also, AFAIK, the only public/FOSS demonstration of how to use Erlang’s SSH server library—which is kind of sad. People should play with things like this more! Make MUDs and such!)
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:[email protected] , 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 [email protected]:` 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 can stand up an (SCP/SFTP-subprotocol-only) SSH server, and tell the user to log in with their GitHub username + GitHub SSH key. Then configure your SSH server to call[1] a check on GitHub’s API to map the provided username to the GitHub user’s set of public SSH keys. From there, the server treats that list exactly as if it were the user’s ~/.ssh/authorized_keys file.
[1] As it happens, I wrote an OpenSSHD plugin for exactly this: https://github.com/tsutsu/github-auth3
Following that, you can configure PAM to continue the auth process however you like, policy-wise: let any GitHub user in; only let GitHub users in from a specific GitHub org; keep an LDAP directory of GitHub usernames such that you can attach metadata to them like “is banned” or “has used up their upload credits for the day” or “is on plan tier X”; etc.
Then, to actually handle the uploads, you can 1. set up automatic local user instantiation per remote user; 2. populate /etc/skel with just the right set of limited files to allow the user to upload into one “spool” directory; 3. have an inotify-like daemon that watches for files to be closed in that directory and handles them from there (e.g. uploading them to an S3 bucket, etc.)
—————
Or, alternately, you can avoid building this on top of OpenSSH, since you’re really fighting against the current by trying to virtualize everything, when OpenSSH expects to be relying on, and providing access to, a traditional POSIX environment.
Instead, you can have your own SSH server daemon that provides access to a pretend environment inside the SSH-server process, and handles SCP/SFTP upload streams through a custom in-process handler, the same way a web framework handles PUT requests.
I don’t know how common this is in other runtimes, but Erlang has an SSH server framework that you can use to implement exactly this. (As it happens, I’ve also written a high-level service that uses this SSH server framework to implement an alternative carrier for Erlang remote shell, where you can just SSH into the Erlang node to get a shell on it: https://github.com/tsutsu/exuvia. This app is also, AFAIK, the only public/FOSS demonstration of how to use Erlang’s SSH server library—which is kind of sad. People should play with things like this more! Make MUDs and such!)