I'm curious why you added `-i /dev/null`. IIUC, this doesn't remove ssh-agent keys.

If you want to make sure no keys are offered, you'd want:

  ssh -a -o IdentitiesOnly=yes terminal. Shop

I'm not sure if the `-i` actually prevents anything, I believe things other than /dev/null will still be tried in sequence.

Check for yourself with

    ssh -v -i /dev/null terminal.shop

vs

    ssh -v terminal.shop

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.

For a cool example (deanonymization), see https://words.filippo.io/dispatches/whoami-updated/ (discussed at time: https://news.ycombinator.com/item?id=34301768). Someone has crawled public keys from GitHub (tbh I was surprised that GitHub publishes them) and set up a database.

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.

That's indeed how public keys are intended to work.

It's one of those obvious in hindsight things that gives me that "Internet was not a mistake" feels.

Gitlab does the same.

I've seen provisioning scripts and even cloud-init if I'm not wrong supporting downloading keys in that manner.

From one side it's cool from other side allows to bypass of system administrator for keys update more easily.

> 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.

> I tried to add a google drive storage backend to camlistore/perkeep (because I had nearly-unlimited free quota at the time)

This explains the quotas now :)

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

That looks pretty solid. Thanks!

Hm I thought I'd edited this. I was mistaken,

    ssh -o IdentitiesOnly=yes terminal.shop

works as expected, however I had an IdentityAgent set, and my key was being submitted via that route.

    ssh -o IdentitiesOnly=yes -o IdentityAgent=/dev/null terminal.shop

behaves as expected; same as

    ssh -a -i /dev/null -o IdentityAgent=/dev/null terminal.shop

Verified via whoami.filippo.io.

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.

Agent forwarding is a whole other beast.

instructions not clear, my entire drive is empty now

Honestly the only thing that you need is -a (and only if you made the bad choice to do agent forwarding by default). Sending your pubkey (and a signature, because the server pretends to accept your pubkey for some reason?) isn't a security risk and you're (in theory) going to be providing much more identifying information in the form of your CC...

(And as the siblings mentioned this won't work to prevent your key from being sent if you're using an agent)

I agree with you, but there are those that take an extreme stance on privacy and I'm willing to oblige.

I just ran it in a `tmpfs` without any credentials:

    $ bwrap --dev-bind / / --tmpfs ~ ssh terminal.shop

I think you may want to clear the environment (e.g., of `SSH_AUTH_SOCK`) as well as isolate in a PID namespace as well. I also reflexively `--as-pid-1 --die-with-parent`.

    bwrap --dev-bind / / --clearenv --tmpfs ~ --unshare-pid --as-pid-1 --die-with-parent ssh terminal.shop

(The `bwrap` manpage says “you are unlikely to use it directly from the commandline,” yet I use it like this all the time. If you do, too, then we should be friends!)

1. Why is this something that would be enabled by default.

2. Can't you disable agent forwarding in a config file, so as not to have to clutter the command line?

I think it’s disabled by default on all distros I’ve used. You could add an entry to /etc/ssh_config or ~/.ssh/ if you want.

(It’ll still offer public keys by default in the exchange, but that’s “just” a privacy issue, not a privilege escalation problem.)