Encrypted SSH Connection Vaults: Keeping Hosts and Keys Out of Plaintext

The default way to store SSH connection details is a plaintext file. ~/.ssh/config holds your hosts, usernames, ports, and jump-host topology in the clear, and your private keys sit next to it protected by nothing more than file permissions and, if you were disciplined, a passphrase. That is fine on a laptop you never lose. It is less fine when the same details need to exist on three machines, or when the file quietly becomes a map of your production estate.

Kubexer Terminal takes a different approach: connections live in vaults that are encrypted on your device, and sync between machines without the server ever being able to read them.

What a vault holds

A vault is a container for three related record types:

• Hosts — the connection itself: address, port, username, and which identity to authenticate with.
• Identities — the credential: a private key or password, stored once and referenced by any number of hosts.
• Groups — organisational structure, so a vault with sixty hosts is still navigable.

Separating hosts from identities matters more than it sounds. In a plaintext SSH config the mapping between a key and the hosts it opens is implicit and scattered. Here it is explicit: one identity record, referenced by name, and you can see at a glance every host a given key can reach. Rotating a key becomes a single edit rather than a search-and-replace across a config file.

How the encryption works

Each vault has its own password, which never leaves your machine. From that password the app derives an encryption key using scrypt, a memory-hard key derivation function chosen specifically because it is expensive to attack with custom hardware — a GPU or ASIC farm cannot brute-force it nearly as cheaply as it could a fast hash like SHA-256. Record contents are then encrypted with AES-256-GCM, an authenticated cipher: it provides confidentiality and integrity together, so a modified ciphertext fails to decrypt rather than silently producing garbage.

The practical consequences are worth stating plainly:

• A vault at rest on disk is ciphertext. Reading the file gives an attacker nothing without the password.
• The vault password is not stored anywhere. It is held in memory while the vault is unlocked and discarded when it is locked.
• There is no recovery path. Lose the vault password and the contents are unrecoverable — by you, and by us. This is the direct trade-off for the server not being able to read your data.

That last point is not a limitation we are apologising for; it is the whole design. A vendor who can reset your encryption password can also read your data, and so can anyone who compromises that vendor.

Zero-knowledge sync

Storing secrets encrypted on one machine is straightforward. The interesting problem is moving them to a second machine without decrypting them in transit or at the destination.

Kubexer Terminal syncs vault records to the backend already encrypted. The server stores opaque blobs. It never receives the vault password, never derives the key, and therefore cannot decrypt a single host address or private key — this is what zero-knowledge means in practice. When you unlock the same vault on another machine with the same password, the records decrypt locally.

Conflict resolution

Because the server cannot read record contents, it also cannot merge them intelligently. Sync therefore operates per record with last-write-wins semantics: each record carries a revision, and the most recent edit takes precedence. Deletions propagate as tombstones — an explicit marker that a record was removed — rather than as an absence, because absence is ambiguous in a distributed system. A record missing from one device might have been deleted there, or might simply never have arrived.

Last-write-wins is a deliberate simplification. It is predictable and it never silently merges two versions of a credential into something that authenticates as neither. If you edit the same host on two machines while both are offline, the later edit wins and the earlier one is discarded.

Host keys travel with the vault

One useful side effect of vault sync: the host keys you have accepted are stored on the host record itself. When you set up a new machine and unlock your vault, the fingerprints you previously trusted come with it. You are not re-prompted to accept every host from scratch, and — more importantly — you do not develop the habit of approving fingerprints without reading them. We cover the trust model in detail in host key verification and TOFU.

Practical setup

A structure that works well for most teams:

1. One vault per trust boundary, not per project. Production and staging in separate vaults means unlocking one does not expose the other.
2. Identities named after the key, not the host. An identity called ops-ed25519 tells you what it is; one called web-01 stops making sense the moment it opens a second machine.
3. Groups by environment or role, so a long host list stays scannable.
4. Use a real vault password — a passphrase, from a password manager. scrypt makes brute force expensive, but it cannot rescue a four-character password.

Where this leaves you

The goal is not encryption for its own sake. It is that the map of your infrastructure and the keys that open it should not be sitting in plaintext on every machine you have ever worked from — and that syncing them between machines should not require trusting a server with the contents. Vaults give you both, at the cost of a password you must not lose.

Kubexer Terminal is available for macOS, Windows, and Linux. See the full feature set.