Creating Identities

What an identity is

An identity in RemoteSignerPhone is one Secure Enclave SSH key plus its metadata: a human-readable label, a creation date, an enabled flag, the algorithm name, the OpenSSH public key string, and a SHA-256 fingerprint. The private key itself never appears in metadata — only the iOS Keychain holds a reference to it, and the Secure Enclave holds the actual bits.

You can have as many identities as you want on a single iPhone. Each one is a distinct SSH key with its own public key line and its own authorized_keys footprint on the servers that accept it.

When to provision a single identity

For most people, one identity is enough. One key on the iPhone, one line in every authorized_keys, every connection signed the same way. This matches how ssh-keygen users typically run a single ~/.ssh/id_ed25519 for everything.

Provision a single identity if:

• You access servers under one administrative scope (your own homelab, your team's prod, whatever).
• You don't have a regulatory or operational reason to separate identities.
• You're starting out and just want it to work.

When to provision multiple identities

Multiple identities make sense when you want different blast radii or different audit trails on different servers. Common patterns:

• Personal vs. work. Two identities, two labels (Personal and Work), each present on the appropriate fleets. Disabling either side lets you cleanly cut off one without rotating the other.
• Per-role. A Read-only audit identity that only appears in authorized_keys on jump hosts; a separate Admin identity that's only in authorized_keys on production servers.
• Per-device-of-yours. If the iPhone is used as the trust anchor for both your Vision Pro and your Mac, you could give each device its own identity so you can tell from server logs which device drove the signature. (Server-side log entries include the key fingerprint.)
• Per-customer or per-client. Consultants who need separate audit trails per engagement.

There is no penalty for having many identities. The list scrolls, each one is independently enabled or disabled, and signing is keyed by which authorized_keys line the server selects.

Provisioning the identity

Tap the + button in the top-right of the home screen, or the Provision Signer button at the bottom. Both open the New Signer sheet.

The sheet has one input — the identity label — pre-populated with Phone Key N where N is the next number. Replace it with whatever you want; the label appears as the OpenSSH key comment, in your server's authorized_keys file, in the Mac's ssh-add -L output, and on the per-request prompt screen. Choose something you'll recognize months later: "MacBook prod", "Doug iPad work", "homelab key" all work.

Tap Create. The system Face ID or Touch ID sheet appears (this is iOS itself, not vmux) authorizing access to the Secure Enclave key generator. After biometrics succeed:

1. The Secure Enclave generates a fresh ECDSA P-256 keypair internally.
2. The private key is bound to your device, your passcode, and userPresence — which means future signatures will require biometrics again.
3. RemoteSignerPhone wraps the public-key portion in OpenSSH wire format, computes a SHA-256 fingerprint over the wire-format blob, and writes the metadata record to its app-private storage.
4. A reference (not the key itself) is stored in the iOS Keychain under service com.vmux.remote-signer.phone.

The new identity appears at the top of the Signers list, enabled by default.

Key type and format

ECDSA P-256 was chosen because it is the only key type the Secure Enclave generates and signs natively. Modern OpenSSH (≥6.5, basically anything since 2014) supports it out of the box; servers that have explicitly removed it from PubkeyAcceptedAlgorithms will need to add it back for these keys to work.

There is no Ed25519 option. There is no RSA option. If you require those algorithms, RemoteSignerPhone will not work for you on those servers — generate a non-Secure-Enclave key elsewhere.

Exporting the public key

Tap an identity's row to open its detail screen. The full OpenSSH key string is selectable text — long-press to use the system Copy menu, or tap the explicit Copy Public Key button. The Status banner confirms the copy.

To get the key onto a Mac or another device, the easiest options:

• AirDrop. Long-press the OpenSSH text, choose Share, and AirDrop to your Mac. The Mac receives it as a text snippet.
• Email draft to yourself. Same Share menu, choose Mail.
• Messages to yourself. Same Share menu, choose Messages and pick a self-conversation.
• Notes / Drive / Files. Paste into any synced document and pull it down on the destination machine.
• Manual typing. The fingerprint displayed above the key is short enough to verify by eye if you need to manually enter the public key — useful for read-only verification, less so for the full base64 blob.

The public key is not secret. Treating it as if it were costs you nothing, but exposing it costs you nothing either; it's the private key (which never leaves the Secure Enclave) that matters.

Renaming an identity

In the detail screen, edit the Label field and tap Save Label. The change persists immediately and propagates next time the iPhone is queried by a paired Mac. If you've already added the public key to a server's authorized_keys, renaming on the phone does not rewrite the comment in the file — the server still has the original. That's harmless, but if you care about consistency, edit the comment portion of the line on the server too.

Enabling and disabling

Each identity has an Enabled toggle. Disabling it:

• Hides it from the list of keys advertised to paired devices (Mac and headset).
• Causes signing requests against the disabled key to fail with the error The selected identity is disabled.
• Does not delete the underlying Secure Enclave key. Re-enabling restores immediate function.

Disabling is a soft revoke. Use it when you want to temporarily stop using a key without going through the trouble of removing it from every server's authorized_keys.

Deleting an identity

Open the identity detail screen and tap Delete Identity at the bottom. A confirmation dialog warns: "Deleting removes the Secure Enclave key reference from your iPhone. Any server using this key will stop authenticating until a replacement key is enrolled." Confirm to proceed.

What gets deleted:

• The Keychain reference (the only handle to the Secure Enclave private key).
• The metadata record in the app's storage.

What does not get deleted:

• The public key line in your servers' authorized_keys. You should remove that yourself with a single sed or by editing the file. Until you do, the line is dead weight — no signature will ever match it again.

There is no undo. Once a Secure Enclave reference is gone, the underlying key cannot be recovered.

Verifying Secure Enclave access

The detail screen has a Verify Secure Enclave Access button. Tapping it asks the Secure Enclave to sign a small fixed test string. Face ID prompts; if it succeeds and the signature comes back, the Status banner reports Verified Secure Enclave access for <label>. Use this if you suspect a key has gone bad — for example, after restoring an iPhone backup, you may find that Secure Enclave keys are present in metadata but invalid (Apple invalidates them on restore by design).

Related

• Pairing and discovery — how the Mac and headset find newly created identities.
• Approving signing — what an actual sign request looks like once your key is in authorized_keys.
• Security — full discussion of why these keys are non-exportable.