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

    ssh terminal.shop

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

  ssh -a -o IdentitiesOnly=yes terminal. Shop

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

    ssh -v terminal.shop

    debug1: Offering public key: /Users/fragmede/.ssh/id_rsa RSA SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

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

Upon further testing,

    ssh -o IdentitiesOnly=yes terminal.shop

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.

> 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

This explains the quotas now :)

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

    ssh -o IdentitiesOnly=yes terminal.shop

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

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

Agent forwarding is a whole other beast.

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

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

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

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

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

Which honestly should always be disabled. There are no trusted hosts.

Just use ssh-add -c to have the ssh-agent confirm every use of a key.

My assessment still stands. Use proxyjump (-J) instead of proxy command whenever possible.

Also very good for other options that are useful but problematic when used with untrustworthy target hosts, like ForwardX11, GSSAPIAuthentication, weaker *Algorithms (e.g. for those old Cisco boxes with no updates and similar crap).

Another neat trick is just using a ""Match *.my-trustworthy-company-domain.com" block" with an "IdentityFile ~/.ssh/secret-company-internal-key" directive. That key will then be used for those company-internal things, but not for any others, if you don't add it to the agent.

As far as I’m concerned the baby and the bath water is just a normal expression.

I thought it was something about the use of “confirm,” haha.

So I can see where someone might count it toward buzzword bingo. But this post also offered an alternate solution when saying "baby+bathwater", so the bingo caller should refuse to score this one.

Learned that rule the hard way. It’s crucial to the success of HN and I am grateful dang corrected me.

Glad that at least a few people above got the joke

So forwarding your SSH agent means an administrator of the system you're connected to could use any of those host keys loaded in the agent to connect to their associated machine.

...your own (headless) server that's in the same room as you, when you're using your laptop as a thin-client for it?

You're allowed to draw sensible boundaries.

I have a private key for my prod server, a private key for GitHub, and a private junk key for authenticating to misc stuff. I can discard any without affecting anything else that's important.

If I authenticated with my junk key, would my other keys still be at risk?

Still I'll be sure to break up my keys more going forward and disable SSH forwarding.

But if you do want to break up your keys more, make sure you specify IdentityFile and Identities Only in the per host definitions in your ssh config.

By default assuming you use an ssh agent (no forwarding) with multiple keys and a default ssh config, the behavior is to just try to auth with every key in order.

So if you're worried about the ssh server identifying you, you're still exposing yourself. I don't think this is much of a concern but worth noting.

Slightly more important: you're wasting time during the initial connection to fail authentication a few times. This can matter more with higher latency

Even more important: sshd has a configurable number of times a client is allowed to fail authentication in a session attempt. If you have too many other keys in your agent you will just fail to auth before it tries the key that is actually valid for that host.

Yes, if you authenticate with your junk key (or no key), and SSH agent forwarding is enabled, you are still at risk. It lets the remote machine login to any server with any keys that are on your local SSH agent. Parent's link shows how this can be abused.

Fortunately, it's disabled by default, at least on newer versions.

If you enable agent forwarding for all hosts then yes, data will be forwarded.

Your link says:

> Don’t enable agent forwarding when connecting to untrustworthy hosts. Fortunately, the ~/.ssh/config syntax makes this fairly simple

  ssh -o PubkeyAuthentication=no -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -a [email protected]

The article you cited makes it clear that you can turn this on for specific hosts in your private SSH config (and probably should do it that way).

So why wouldn't you?

Turning on forwarding globally and then having to remember to disable it for some untrusted hosts with -a looks silly and error-prone to me.

They can't get your private keys, but they could "perform operations on the keys that enable them to authenticate using the identities loaded into the agent" (quoting the man page). This would also only be possible while you are connected.

Not at all specific to this.

It's also good to see if any malicious process tries to make use of the agent locally!