What you're looking for is that there is no line that says something like
debug1: Offering public key: /Users/fragmede/.ssh/id_rsa RSA SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Upon further testing, the full command you want is:
ssh -a -i /dev/null -o IdentityAgent=/dev/null terminal.shop
to forcibly disable a local identity agent from offering up its identities as well, and not just agent forwarding.
Upon further testing,
ssh -o IdentitiesOnly=yes terminal.shop
still offers up my public key on my system (macOS, OpenSSH_9.6p1, LibreSSL 3.3.6), contrary to what StackOverflow and the Internet seems to think. Tested by hitting whoami.filippo.io, linked in child comment.
Aha, yes, `-o IdentityAgent=/dev/null` is better for my intent. I was confused that `-i` wasn't removing .ssh/id_rsa from the candidates, but that was ssh-agent.
ssh -a -i /dev/null -o IdentityAgent=/dev/null terminal.shop
It's quite useful! I can give someone access to my server by grabbing their public key and creating an account for them, no need figure out how to send them the password to my server.
> You can make a search for all users, which will tell you there are 97,616,627 users at the time of this writing, but you can only fetch at most 1000 results from a search, and they don’t come in any clear order, so you can’t just make the next search start where the previous one left off (or I didn’t figure out how).
> What you can do though is request accounts created in a certain time range. If you get the time range right, so that it has less than 1000 entries, you can paginate through it, and then request the next time range.
This reminds me of when I tried to add a google drive storage backend to camlistore/perkeep (because I had nearly-unlimited free quota at the time). One of the things a perkeep blobserver needs to be able to do enumerate all the blobs it has, in order. You can send millions of blobs to google drive without issue, but you can't directly paginate a search for them in sorted order.
You could just issue a search for all blobs under your perkeep drive folder, keep paginating the result until you run out of pages, and then sort in memory, but there's really no way of knowing how many blobs you're going to end up with and you might blow out your blobserver's memory.
Perkeep blobs are identified by blobrefs, SHA sums of the contents of the blob, so they look like sha-[0-9a-f]{64}. Google drive lets you search for files with a name prefix, so you can search for like /perkeep/sha-* and see if the result has a pagination token (indicating that there are more than 1000 results), and if so then you search for each of /perkeep/sha-0*, /perkeep/sha-1*, ... , /perkeep/sha-f*, each time checking to see whether there are too many matches. When there's not too many matches, you've found the prefix length that will let you fetch a bounded number of blobrefs, emit them to the perkeep client, and then release the memory before fetching more.
/pk/sha-\* 1000+ results (non-empty pagination token)
/pk/sha-0\* 1000+ results (non-empty pagination token)
/pk/sha-00\* 1000+ results (non-empty pagination token)
/pk/sha-000\* 193 results,
sort these in memory and emit to client
/pk/sha-001\* 179 results,
sort these in memory and emit to client
...
/pk/sha-fff\* 223 results,
sort these in memory and emit to client
I didn't end up landing the patch before I lost interest, partly because it was pretty much the first golang I had tried writing. It was fun working out the above details, though.
Offering your public key only allows them to identify the key and prove you have it. There is no security concern in sending this to an untrusted server.
If you want to make sure no keys are offered, you'd want:
I'm not sure if the `-i` actually prevents anything, I believe things other than /dev/null will still be tried in sequence.