SSH Keys on Netrouting: Store Once, Use on Every Server and VM (Portal and API)

Method 1: In the portal

Store a key

1. Log in at amoni.app and pick SSH Keys from the left-hand menu.
2. Under Add a key, give it a name you'll recognize later (work laptop, ci-runner) and paste in what's in the .pub file.
3. Click Add key. The key shows up in the list with its fingerprint. Paste something that isn't an OpenSSH public key and the portal turns it down, telling you what a valid one starts with. A key you've already stored is refused too, and the message names it.

Deleting a key here (the trash icon) only takes it off the list. Machines that already have it keep it until their next reinstall or rebuild. To get it off a running machine, edit ~/.ssh/authorized_keys on that machine, or use the live update below.

Use keys on a fresh system

• Bare metal: on the server's Reinstall tab, tick the stored keys you want under SSH Keys, or paste in extra ones. Details: reinstall the operating system.
• Cloud: in the Rebuild VM dialog, the keys are listed under SSH keys for the new system; tick the ones you want. See rebuild.

The server's own SSH Keys tab shows the same list read-only, so you can see what a reinstall is going to offer.

Apply keys to a running cloud instance

1. Go to the instance and open its SSH Keys tab.
2. Tick every key that should be on the machine. The button keeps count: Apply to VM (1).
3. Click Apply to VM. That writes the selected set to the machine's provisioning drive, where it replaces whatever was applied that way before.
4. From the instance header, do a Stop and then a Start. That's what regenerates the provisioning drive. A plain reboot doesn't, so the keys would never land.

Use in rebuild, on the same tab, opens the rebuild dialog with those keys already selected. Use it when you wanted a fresh system anyway.

Method 2: With the API

Changing the key store takes the SSH Keys scope (sshkeys.write), while listing it takes read. Applying keys to an instance needs vms.write. Reference: api.amoni.app/v1/docs.

Store a key

curl -s -X POST https://api.amoni.app/v1/ssh-keys \
  -H "Authorization: Bearer nr_live_..." \
  -H "Content-Type: application/json" \
  -d "{\"name\": \"ci-runner\", \"public_key\": \"$(cat ~/.ssh/id_ed25519.pub)\"}"

{ "success": true, "data": { "id": 42, "fingerprint": "SHA256:Zt3v9Qk2mXpL7r4w...", "key_type": "ssh-ed25519" } }

List and delete

curl -s https://api.amoni.app/v1/ssh-keys -H "Authorization: Bearer nr_live_..."

{ "success": true, "data": [ { "id": 42, "name": "ci-runner", "public_key": "ssh-ed25519 AAAA...", "key": "ssh-ed25519 AAAA...",
    "fingerprint": "SHA256:...", "key_type": "ssh-ed25519", "created_at": "2026-09-15 10:12:00" } ] }

key is a copy of public_key. Both stay in the response so older clients keep working.

curl -s -X DELETE https://api.amoni.app/v1/ssh-keys/42 -H "Authorization: Bearer nr_live_..."

Use the ids everywhere else

Pass stored key ids as ssh_key_ids to POST /v1/servers/{id}/reinstall and POST /v1/vms/{accountId}/{vpsId}/rebuild. Raw keys, one per line, go in sshkeys, and you can send both in the same call.

Apply to a running instance

curl -s -X PUT https://api.amoni.app/v1/vms/990204/411/ssh-keys \
  -H "Authorization: Bearer nr_live_..." \
  -H "Content-Type: application/json" \
  -d '{"ssh_key_ids": [42]}'

{
  "success": true,
  "data": {
    "username": "root",
    "applied": [ { "name": "ci-runner", "fingerprint": "SHA256:..." } ],
    "pasted_key_count": 0,
    "message": "Keys saved to the machine's provisioning drive. ..."
  }
}

Then stop and start the instance (POST .../power with stop, then start) to regenerate the drive. Container-type instances don't have a provisioning drive, so for them the call answers 422 and keys land only at creation.

What the API will tell you