tempssh

A Ratatui interface for creating and deleting short-lived OpenSSH user certificates. It generates a fresh client key, signs it with your SSH certificate authority, and keeps the resulting key pair under one managed directory.

tempssh delegates all key and certificate operations to the installed OpenSSH ssh-keygen. Hardware prompts therefore use the normal OpenSSH/FIDO/PKCS#11 path rather than custom cryptography.

Features

• Short certificate lifetimes from 15 minutes to 7 days
• Multiple SSH principals and optional source-address CIDR restrictions
• Restrictive certificate defaults: only permit-pty is enabled
• Ephemeral Ed25519 client keys or hardware-backed Ed25519-SK client keys
• Three CA signing backends:
  • File / FIDO handle — software CA private keys and FIDO2 *-sk key-handle files
  • SSH agent — including hardware-backed keys loaded into ssh-agent
  • PKCS#11 — smart cards and HSMs through an OpenSSH provider library
• Expiry status, individual deletion, and bulk cleanup of expired keys
• In-UI ssh-copy-id bootstrap for authorizing the CA on remote accounts
• oneshot CLI mode: create, sign, and authorize a server with a single command
• One-key clipboard copy of the selected identity's SSH command

Build and run

Requirements: Rust and OpenSSH (ssh-keygen and ssh-copy-id). FIDO keys require an OpenSSH build with security-key support.

cargo install --path .
tempssh

The first launch opens the small signer setup dialog. CA paths accept ~, $HOME, pasted quotes, or a bare filename from ~/.ssh. In direct mode, entering the matching .pub path automatically resolves to its private/FIDO handle when present.

Configuration is saved to:

$XDG_CONFIG_HOME/tempssh/config
# default: ~/.config/tempssh/config

Managed keys are stored with a 0700 directory mode under:

$XDG_DATA_HOME/tempssh/keys
# default: ~/.local/share/tempssh/keys

Hardware-backed CA signing

FIDO2 / security key

Create an Ed25519-SK CA. The small private-key file is only a key handle; the private key material remains in the authenticator.

ssh-keygen -t ed25519-sk -O resident -f ~/.ssh/tempssh_ca_sk

In tempssh, press s and select:

CA private key / public key: ~/.ssh/tempssh_ca_sk
Signing backend:             File / FIDO handle

Every certificate signature will require the authenticator. tempssh temporarily leaves the alternate screen so OpenSSH can request a PIN and/or touch normally.

A non-resident FIDO key works too; omit -O resident. Keep the generated key-handle file because OpenSSH needs it to address the key on the device.

SSH agent

Load the CA key into the agent, then select the SSH agent backend:

ssh-add ~/.ssh/tempssh_ca_sk
tempssh --signer agent

If the agent has exactly one key, the CA path may be left empty. With multiple keys, enter the CA public-key path or its unique agent comment. This uses ssh-keygen -U -s ...; the CA private key is requested from ssh-agent and can still require hardware presence.

PKCS#11 token or HSM

tempssh \
  --signer pkcs11 \
  --ca ~/.ssh/ca_from_token.pub \
  --pkcs11 /path/to/provider.so

The CA path is the token key's OpenSSH public key. The provider path is passed to ssh-keygen -D.

Trust the CA on SSH servers

Copy only the CA public key to the server and configure sshd:

TrustedUserCAKeys /etc/ssh/user_ca.pub

Restart or reload sshd after validating its configuration. The certificate principal must be accepted as a login name, either directly or through an AuthorizedPrincipalsFile/AuthorizedPrincipalsCommand policy.

Connect with the command shown below the key list:

ssh -i ~/.local/share/tempssh/keys/<id>/id user@host

OpenSSH automatically discovers the adjacent id-cert.pub certificate.

Authorize a remote account from the TUI

Select a certificate and press c. Enter [user@]host and an optional SSH port. tempssh runs ssh-copy-id interactively, so host-key, password, and MFA prompts remain visible.

It installs the CA public key in the remote account's authorized_keys using cert-authority and restricts it to the selected certificate's principals. It does not install the temporary raw client key, so certificate expiry remains enforced.

One-shot bootstrap from the CLI

tempssh oneshot creates and signs a temporary key, then authorizes a remote account — one command, no TUI:

tempssh oneshot deploy@server.example.com

It uses the configured signer (or --ca/--signer overrides), defaults the principal to the login user and the lifetime to one hour, runs ssh-copy-id interactively so password and MFA prompts stay visible, and prints the ready-to-use ssh command when done. Options:

-p, --port PORT        SSH port on the server
-n, --principals LIST  comma-separated certificate principals (default: login user)
-t, --ttl TTL          15m, 1h (default), 4h, 8h, 1d, or 7d
--identity NAME        certificate identity label
--hardware-key         use a FIDO2 ed25519-sk client key

The key pair is kept in the managed store, so it also appears in the TUI list for later deletion.

Keys

Key	Action
n	Create and sign a temporary key
s	Configure the CA signing backend
c	Authorize a remote account using ssh-copy-id
y	Copy ssh -i <identity> principal@host to the clipboard
j / k, arrows	Select a key
d	Delete the selected private key and certificate
x	Delete all expired managed keys
r	Refresh
q, Ctrl-C	Quit
Tab, Shift-Tab	Move through a form
Left/right	Change a choice

CLI and environment

--ca PATH
--signer direct|agent|pkcs11
--agent
--pkcs11 PATH
--store PATH
oneshot [user@]host [-p PORT] [-n LIST] [-t TTL] [--identity NAME] [--hardware-key]

Equivalent environment variables are TEMPSSH_CA, TEMPSSH_SIGNER, TEMPSSH_PKCS11, and TEMPSSH_STORE.

Security notes

• This is an SSH certificate tool, not an X.509 certificate tool.
• Software client private keys are intentionally unencrypted so they can be used unattended during their short certificate lifetime. Delete them when finished; x removes expired keys.
• Expiry is enforced by servers that authenticate through the configured CA. The c action installs CA trust rather than the raw client key.
• File deletion is normal filesystem deletion, not guaranteed secure erasure on SSDs or copy-on-write filesystems.
• Protect the CA with hardware, a passphrase, or a constrained agent. Never copy the CA private key to SSH servers.