Password management is an unavoidable part of building a desktop SSH tool.
The simplest approach is to store a password with each connection’s configuration. It works in the short term, but becomes painful when moving to a new machine, reinstalling, or sharing a connection configuration with a colleague. Passwords end up scattered across dozens of connections. Worse, exporting configurations for backup can carry credentials along with them.
The principle: use the system’s secure storage
My principle is simple: sensitive credentials in desktop tools belong in operating-system secure storage. On a Mac, that means Keychain. It provides system-level encryption, unlocking policies, and authorization prompts that are difficult to improve on with a custom encrypted file.
Docklark’s direction is therefore to bring connection passwords together in one SSH password vault backed by macOS Keychain, rather than keeping independent password fields in each connection.
Memory caching: avoid a stream of Keychain prompts
Accessing Keychain can trigger an authorization prompt. In a client with multiple windows and connections, reading it every time a password is needed can make the experience frustrating.
The vault adds a shared in-memory cache above Keychain. Windows and connections use the same cache so that authorization does not need to interrupt the session repeatedly. Password additions, edits, and removals pass through this layer before being persisted to Keychain.
Migration is the difficult part
Storage is not the hardest part. Migration is: passwords saved separately in existing connections need to move into the shared vault.
Docklark makes this an explicit, centralized process that can resume after an interruption. A failure partway through, such as a locked Keychain or an entry that temporarily cannot be read, does not require starting over. Once the issue is resolved, migration continues where it stopped.
The most important rule is read-back verification. After writing a password to the new vault, read it back and compare it with the old entry. Only remove the old copy after verification succeeds. That extra read-back check reduces the risk of reporting a successful migration while losing a password, but it does not replace thorough migration testing.
Keys are a separate concern
Passwords are only one part of authentication. Docklark supports generating Ed25519, RSA, and ECDSA keys, importing and exporting OpenSSH formats, displaying fingerprints, and copying public keys. Fingerprint verification is prominent because choosing the wrong file is an easy mistake when importing a key.
Docklark’s JSON connection-configuration import and export do not include credentials. Configurations can be shared and backed up separately, while passwords and keys stay in their respective credential stores.
Limits still being checked
The shared vault is still undergoing acceptance testing. The checklist includes Keychain migration between installed versions, behavior with a locked Keychain, system authorization prompts, and real SSH logins using the new vault. I will not call it proven until that verification is complete. Progress remains on the Docklark project page.