Security

Security

Credentials

Passwords live only in the OS keychain (via the keyring crate). They are never written to hosts.toml, logs, or the terminal. Add them with Ctrl+K.

macOS re-prompts for keychain access after each update — that's expected. "Always allow" is tied to the binary's code signature, and each new (unsigned) build is a new identity, so macOS re-verifies. It's a genuine protection, not a bug.

SSH private keys

When a host uses identity_file, gukab stores only the file path — never the key bytes. The key stays on disk where you keep it; the passphrase (if any) is read from the OS keychain at connect time and never written to config. On load, a key file readable by group/other triggers an OpenSSH-style warning (chmod 600 recommended) but is not blocked, since the key never leaves your own disk.

Host-key verification (trust-on-first-use)

On first connect, a server's SSH host-key SHA-256 fingerprint is recorded in ~/.config/gukab/known_hosts. On later connects, gukab refuses to connect if a known host's key has changed (possible MITM).

To accept a legitimate key change (device reimaged, replaced, etc.), remove that host's line from ~/.config/gukab/known_hosts and reconnect.

File permissions

hosts.toml, known_hosts, and session logs are written owner-only (0600), and log directories 0700. Session logs can contain sensitive command output (e.g. show running-config) — review retention for your environment. Passwords typed at prompts are not captured (the remote does not echo them).

Known advisory

RUSTSEC-2023-0071 (Marvin timing side-channel in the transitive rsa crate) has no upstream fix yet. Practical impact here is low — gukab is an SSH client and verifies RSA server signatures rather than performing RSA private-key decryption. It will be resolved when rsa ships a fix.