On NEAR, how to delete all keys other than the FullAccess key that my Ledger seed phrase created

I want to delete all keys other than the FullAccess key that my Ledger seed phrase created.

When I check which keys are associated with my NEAR Ledger account, I see some like:

"access_key": {
      "nonce": "aaaaaaaa",
      "permission": {
        "FunctionCall": {
          "allowance": "0",
          "method_names": [
            "__wallet__metadata"
          ],
          "receiver_id": "bbbbbbbbbbbbbbbb"
        }
      }
    },
    "public_key": "ed25519:cccccccccccccc"
}

(fake values above)

I tried:

NEAR_ENV=mainnet near delete-key bbbbbbbbbbbbbbbb cccccccccccccc --useLedgerKey
Make sure to connect your Ledger and open NEAR app
Deleting key cccccccccccccc on bbbbbbbbbbbbbbbb.
Waiting for confirmation on Ledger...
An error occured
DisconnectedDeviceDuringOperation: Cannot write to hid device
    at new CustomErrorClass

What should I have done instead?

Also, note that someone should fix "occured" to "occurred".

Solution

There may have been an issue with USB connectivity.

The command in this syntax:

NEAR_ENV=mainnet near delete-key bbbbbbbbbbbbbbbb cccccccccccccc --useLedgerKey

did indeed work when the Ledger was plugged directly into my laptop (rather than into a USB switch connected to my laptop) and was logged in with its NEAR app open.

Oddly, it made me confirm the public key of its FullAccess key 3 times before then also (unsurprisingly) making me confirm the deletion of the cccccccccccccc key.

But it worked!

Now when I run NEAR_ENV=mainnet near keys bbbbbbbbbbbbbbbb, I see just the FullAccess key, so I've achieved my goal.

(Note that in my question and in this answer, I've replaced real values with fake ones.)

UPDATE:

Actually, when running NEAR_ENV=mainnet near send xxxxxxx yyyyy 1 --useLedgerKey, even when plugged directly into my laptop, I got this error:

Waiting for confirmation on Ledger...
An error occured
Error
    at new TransportError ...

But then I ran it again, and it worked, although it again weirdly made me confirm the public key of its FullAccess key 3 times before then also (unsurprisingly) making me confirm the transfer. So I don't know what the root cause of either issue was, but trying multiple times seems to have been an effective enough workaround.