I had a dozen SSH keys spread over a few machines and no way to answer simple questions about them. Which ones still have no passphrase? Which are 1024-bit leftovers I generated years ago and forgot? Which private key is sitting at 0644? Every answer meant another pass of ssh-keygen -lf, stat and grep across ~/.ssh, and I never did it often enough. Editing ~/.ssh/config had the opposite problem: it is a file I had hand-tuned for years, where my own comments and host ordering carry meaning, and nothing would tell me that a directive I pasted from a StackOverflow answer had quietly disabled host key checking.
Demo
Terminal previewOverview
Terminal UI for managing SSH keys and auditing security
Terminal UI to manage SSH keys, edit ~/.ssh/config, and audit your SSH security. Encrypted metadata + backups, an A–F security grade, byte-identical config editing. Single static binary, offline, no daemon.
From the maintainer
Open keyward and go straight to the audit. It grades your setup A-F and lists each finding with a concrete fix: a key with no passphrase, a 1024-bit RSA key, a private key with loose permissions, a config directive that weakens host verification. Fix the ones you agree with, re-run, and watch the grade move. It takes about a minute, and on a machine you have been using for a few years it almost always surfaces something you did not know was there.
The ~/.ssh/config editor round-trips byte-for-byte. Every line, comment, blank and piece of indentation is preserved as a token, so writing the file back after changing nothing produces identical bytes, and changing one directive touches only that directive. Your config is a file you have tuned by hand, so a tool that silently reformats it is a tool you stop trusting after the first commit diff. The rest follows from the same rule: fully offline, no daemon, no telemetry, one static binary, and an encrypted vault (age + argon2id) that never holds anything but metadata.
v1.0.x is a stability line: the on-disk format and the CLI surface are under semver now, so breaking either means 2.0. The nearest piece of work is support for the Include directive, so split multi-file configs work end to end. After that the two directions I care about are widening the audit itself (duplicate fingerprints, SSH certificate detection, agent socket permissions) and hardware-backed keys, sk-ssh-ed25519@openssh.com and FIDO2, which would meaningfully extend what the audit is able to say about a setup. Directions rather than commitments, and issues do move the order.
Latest Release
Changelog
- bcba479e1e25e3d11c7a8cc79e0d721949d994de: chore(release): 1.0.3 changelog (@gateway-of-last-resort)
- 0773211348741049f1409453153c520eb4f8d5e7: ci: bump Go to 1.26.6 (asn1 GO-2026-5972) (@gateway-of-last-resort)
- e5a5ec9348310bdfe6c21d3d7b6e6e37c6fe2326: fix(audit): honour IdentityFile in the global config block (@gateway-of-last-resort)
- b0eec07056801fbf038e060295e648879dd0b19f: fix(crypto): wrap master key read errors in a sentinel (@gateway-of-last-resort)
- bd2c9b50de0b0d31db7942324c9aca4a4a54fd93: fix(storage): keep the public half's read bits on restore (@gateway-of-last-resort)
Discussions