Documentation
Keys and the agent
The Keys section stores identities the vault can use for SSH. A host lists the keys it should try, in order. A group can supply that list to every host under it.
Where a key lives
| Kind | Where the private key is | Sync |
|---|---|---|
| File key: Ed25519, ECDSA, or RSA | In the vault, encrypted | The whole key |
| Secure Enclave, ECDSA P-256 | The Secure Enclave of one Mac. The vault keeps a device-bound blob. | Public part only |
FIDO2, sk-ssh-ed25519 or sk-ecdsa |
On the hardware key. The vault keeps the key handle. | Handle and public part |
| Android Keystore, ECDSA P-256 | Android Keystore, StrongBox when the device has it | Public part, same idea as an enclave key: it does not leave the phone |
Secure Enclave protection is chosen when the key is created: Touch ID or the Mac password (the default), Touch ID only, or, under Advanced, no prompt. The key never leaves the chip, so each Mac has its own key. Add each public key to authorized_keys on the servers that should accept it. A vault copied to another Mac lists these keys as “on another Mac” and cannot use them.
FIDO2 needs a touch. Skip stops TermiPort waiting at once, but the key can keep blinking for about 30 seconds and answer “busy” to the next operation. FIDO2 items are hidden on Android. A vault that unlocks with a security key still opens with the password there. Waiting for a touch cannot be aborted on the key itself.
Android Keystore keys are created on that phone and used by SSH and the built-in agent. Biometric confirmation uses the system prompt.
The built-in agent
Settings → Agent starts the agent. It serves vault keys, Secure Enclave keys, and FIDO2 keys.
- Run the SSH agent — listen on a socket. The path is shown, with Restart.
- Set SSH_AUTH_SOCK in local tabs — local terminal tabs receive the socket.
- When the vault is locked — Ask to unlock (the default) or Refuse. Forwarded requests never ask to unlock.
- Ask before each use of a key by a local program — on by default for file keys and for Secure Enclave keys that have no prompt of their own.
Use from other programs shows an SSH_AUTH_SOCK line and an IdentityAgent line you can copy. The agent lives only while TermiPort is running. Quitting removes the socket. The path is not an authorization boundary: any process of the same user on that Mac can connect. On Android there is no socket for other apps. The agent still forwards keys on SSH connections from TermiPort itself.
Recent requests lists the time, the source, the key, the destination, and the result.
Forwarding
Turn on Forward agent on a host or a group. Forwarded keys chooses which keys that host may use: the host’s own keys, all keys, or a selection. Forwarded requests always ask, except for keys that already need Touch ID or a touch.
This is also how sudo through pam_rssh can use a Touch ID key: the key stays in the Mac’s Secure Enclave, and the forwarded agent signs on the server’s behalf after you approve it.
Unlocking the vault with a key
That is separate from SSH keys. Settings → Security → Use a Security Key Instead of the Password… can replace the master password with a FIDO2 key and its PIN, on a Mac. TermiPort then shows a recovery code once. Without that code or a backup key, a lost security key means a lost vault. Touch ID, if it was already on, keeps working. Android does not offer this path.
An authenticator code on the vault (Ask for an authenticator code) is a second check after the master password. It does not encrypt the vault. Touch ID does not ask for it. The sync account has its own second factor, described under Vault and sync.