phacility/phabricator · error · PhutilArgumentUsageException

The public key corresponding to the given private key is pro

Error message

The public key corresponding to the given private key is properly associated with the device, but is not yet trusted. Trust this key before registering devices with it.

What it means

Usage exception from `bin/almanac register`: the public key matches the right device and is active, but its trusted flag is false. Almanac distinguishes uploaded keys (untrusted, no host authority) from trusted keys (a human has verified the key really represents the device); only trusted keys can register hosts. Trust is granted out-of-band by an administrator with `bin/almanac trust-key`.

Source

Thrown at src/applications/almanac/management/AlmanacManagementRegisterWorkflow.php:171

    }

    if ($public_key->getObjectPHID() !== $device->getPHID()) {
      $public_phid = $public_key->getObjectPHID();
      $public_handles = $viewer->loadHandles(array($public_phid));
      $public_handle = $public_handles[$public_phid];

      throw new PhutilArgumentUsageException(
        pht(
          'The public key corresponding to the given private key is already '.
          'associated with an object ("%s") other than the specified '.
          'device ("%s"). You can not use a single private key to identify '.
          'multiple devices or users.',
          $public_handle->getFullName(),
          $device->getName()));
    }

    if (!$public_key->getIsTrusted()) {
      throw new PhutilArgumentUsageException(
        pht(
          'The public key corresponding to the given private key is '.
          'properly associated with the device, but is not yet trusted. '.
          'Trust this key before registering devices with it.'));
    }

    echo tsprintf(
      "%s\n",
      pht('Installing public key...'));

    $tmp_public = new TempFile();
    Filesystem::changePermissions($tmp_public, 0600);
    execx('chown %s %s', $phd_user, $tmp_public);
    Filesystem::writeFile($tmp_public, $raw_public_key);
    execx('mv -f %s %s', $tmp_public, $stored_public_path);

    echo tsprintf(
      "%s\n",

View on GitHub (pinned to 5720a38cfe)

Solutions

  1. Find the key ID (device -> Manage -> SSH Keys shows it, or the register error trail), then run: bin/almanac trust-key --id <key-id>.
  2. Re-run bin/almanac register; it should now install the key files.
  3. For rotation, fold trust-key into the same scripted step that uploads the new public key.

Example fix

# before
$ sudo bin/almanac register --force --device web-001 --private-key web001.key
Usage Exception: ... is not yet trusted. Trust this key before registering devices with it.

# after
$ bin/almanac trust-key --id 42
$ sudo bin/almanac register --force --device web-001 --private-key web001.key
Defensive patterns

Strategy: validation

Validate before calling

// Automation: upload key, trust it, then register
// 1) upload via UI or auth SSH key API on the device
// 2) trust:
//    bin/almanac trust-key --id <key-id>
// guard before register:
if (!$match->getIsTrusted()) {
  throw new RuntimeException('Trust the device key first: bin/almanac trust-key --id '.$match->getID());
}

Try / catch

# scripted trust-then-register
bin/almanac trust-key --id "$KEY_ID" || true
grep -q 'already trusted' <(bin/almanac trust-key --id "$KEY_ID" 2>&1) || true
sudo bin/almanac register --force --device "$D" --private-key "$K"

Prevention

When it happens

Trigger: Following the error-34 fix flow (new key uploaded to device) without running the trust step; a freshly rotated key that was never re-trusted; an admin revoked trust during an incident and re-registration is attempted.

Common situations: New cluster bring-up where the runbook skips `bin/almanac trust-key`; key rotation procedures that forget re-trusting; CI registering ephemeral drydock hosts with newly minted keys.

Related errors


AI-assisted analysis of phacility/phabricator@5720a38cfe (2026-08-21). Data as JSON: /api/errors/f7a1d8dcb190c3e9. Report an issue: GitHub.