sshkeeper

sshkeeper v0.8.6 — password-only sync recovery

Changed

• New installations restore an existing encrypted sync with the storage

location and original vault master password. No device pairing is required.

• Creating a sync space publishes a separately encrypted, password-recoverable

copy of the random 256-bit sync key.

• Existing spaces can enable the new workflow in place without rewriting

existing encrypted bundle data. Recovery keys and legacy pairing CLI remain

compatible for older installations.

• The TUI no longer shows device pairing controls. A recovery-password action

lets existing users enable or update the password needed for new restores.

• Folder sync stores the access envelope in sshkeeper.access; Git sync uses

the dedicated sshkeeper-access branch to avoid interference from old clients.

• Tests cover new/legacy restore, wrong passwords, SSH private keys and secrets,

orphaned access files and Git storage.

Security note

A stolen password-protected access file **can be subjected to offline master

password guesses**, unlike the previous randomly keyed recovery-only approach.

The key wrapper uses Argon2id (128 MiB, three passes) and XChaCha20-Poly1305.

Use a strong unique master password and restrict remote storage permissions.

Server-side version history is needed to recover from deletion or rollback.

Upgrade notes

• Existing devices continue syncing normally; on an already connected machine

choose Enable / update password recovery (or

sshkeeper sync enable-password) once before replacing all devices.

• After changing your original master password, re-publish recovery with the

new password; existing joined devices keep their locally saved random key.

• If the original installation is already gone and migration was never

enabled, restoring an old bundle still needs its random recovery key.

Открыть релиз на GitHub ↗

Automated build from the tip of main, rebuilt on every push.

This is not a stable release. It is untagged, unannounced and may be

broken. The Latest badge stays on the newest v* release, which is

what you want for normal use.

| | |

|---|---|

| Version | v0.8.5-4-g6718822 |

| Commit | 6718822a4656d9073468d4722f726f81ff07bde9 |

| Built | 2026-10-18 23:24 UTC |

Verify downloads against checksums.txt.

Открыть релиз на GitHub ↗

sshkeeper v0.8.5 — terminal-style mouse selection

Fixed

• Drag-to-scroll selection. Holding a mouse selection against the top or

bottom edge automatically scrolls through SSH output. The selected range can

extend well beyond the visible terminal rows. Timers run only while dragging

at an edge and stop when the drag ends.

• Mouse wheel preserves selection. Scrollback may be browsed before or

after releasing the mouse button, without losing the highlighted range.

• Double-click selects a word. Unicode letters, digits and underscores

count as word characters. Dragging extends the range by full words.

• Triple-click selects a line. Dragging extends the range by full lines,

in either direction. Single-character dragging remains unchanged.

• Usual mouse features retained. Clickable tabs, scrolling and automatic

clipboard copy on mouse release still work.

Regression tests cover Unicode, punctuation, word/line drags, selection across

scrollback, repeating edge scrolling, wheel preservation, multi-click timing,

clipboard copy and cancelled timers.

Открыть релиз на GitHub ↗

sshkeeper v0.8.4 — copy from SSH tabs and close completed sessions

Improved

• Text selection without Shift. Left-button drag in an embedded SSH tab

highlights text and copies it to the system clipboard on release. Selection

supports Unicode, multiple lines and the scrollback viewport. Native clipboard

support is used where available; terminal OSC 52 is a fallback.

• Successful SSH exit closes its tab. Clean remote shell exit (status 0)

removes the workspace tab automatically. If that tab was in the background,

focus stays on the current workspace. The last tab returns to Servers.

• Failures remain inspectable. Nonzero SSH exit status or connection errors

retain the terminal output and error in the tab until manually closed.

• No regression to navigation. The terminal mouse wheel still scrolls output,

and clicking the tab strip still switches tabs.

Automated regression tests cover text selection, scrollback, Unicode, clean

exits and failed SSH processes. Normal tmux-backed persistent sessions remain

independent from the embedded PTY/ConPTY workspace.

Открыть релиз на GitHub ↗

sshkeeper v0.8.1 — Windows workspace input fixes

v0.8.1 fixes two input regressions found during the first native-Windows test of

the v0.8 Session Workspace.

Fixed

• Mouse clicks now select the row actually clicked. The dashboard header is

two terminal rows (title plus separator), but v0.8.0 mouse hit-testing counted

it as one. On the server list this selected the next visible row, e.g. clicking

kp_gate selected KP_Mail.

• Reliable workspace cycling on native Windows. Bubble Tea 1.3.x discards

the Ctrl modifier from native Windows PageUp/PageDown console events, so

Ctrl+PgUp / Ctrl+PgDn cannot be distinguished there. SSHKeeper now also

supports Alt+Left / Alt+Right for previous/next workspace tab. The

original Ctrl+PageUp/PageDown shortcuts remain available on terminals that

report them correctly.

Regression tests cover grouped server-list mouse coordinates and the new

workspace cycle shortcut.

Открыть релиз на GitHub ↗

sshkeeper v0.8.0 — Session Workspace

v0.8.0 turns the main TUI into a live SSH workspace. Interactive SSH no longer

has to replace the sshkeeper interface: sessions live in embedded tabs and can

keep running while you return to the dashboard, manage tunnels, or open another

server.

Added

• Embedded SSH tabs on every platform. Normal Connect opens a workspace tab.

Unix uses a PTY; native Windows uses ConPTY. Terminal state is rendered by

github.com/charmbracelet/x/vt, so full-screen terminal applications can keep

running while another tab is active.

• Workspace tab switching. Ctrl+PgUp / Ctrl+PgDn cycle tabs, Alt+0

returns to Servers, Alt+1…Alt+9 select an SSH tab, and Alt+W closes the

current SSH tab.

• Selected-profile actions. On the wide dashboard press Tab to focus the

right panel. It can Connect, Tunnel + Connect, start/stop a background tunnel,

or open the full port-forward editor.

• Tunnel + Connect. Enabled forwards start as an independent background

ssh -N process, then sshkeeper opens an interactive SSH tab. The tunnel can

be stopped later without closing the session.

• Mouse input. Bubble Tea mouse events are enabled. The dashboard supports

wheel navigation, server selection, clickable right-panel actions, and

clickable workspace tabs.

Changed

• Dead background tunnel records are garbage-collected from tunnels.json on

load/reload, including their temporary SSH config files.

• The Running tunnels manager reloads and shows live processes rather than

retaining stopped entries from old sshkeeper runs.

• Quitting with live embedded SSH tabs asks for confirmation.
• The existing tmux backend remains available on Linux/macOS as an optional

persistent backend for sessions that should survive the sshkeeper process.

Windows

The Session Workspace is native on Windows and uses the same ConPTY foundation

as password/key-passphrase authentication. The ConPTY child environment now

defines TERM=xterm-256color, so remote full-screen applications receive a

terminal type even when sshkeeper was launched from cmd.exe. No tmux, MSYS2,

or Cygwin layer is required.

Compatibility

No database migration is required. v0.8.0 includes the v0.7.6 quiet-sync

key-path repair, so Windows clients upgraded from older releases repair legacy

/home/.../.ssh/... identities even when the shared sync bundle itself has not

changed.

Открыть релиз на GitHub ↗

sshkeeper v0.7.6 — repair local key paths on a quiet sync

v0.7.6 fixes the remaining upgrade case where the shared sync bundle is

already correct but a local Windows profile still points at a Linux identity

path.

Fixed

• Local repair no longer depends on Incoming records. Before merge, sync

now checks already-synchronized profiles against the remote key records and

repairs device-local key paths independently from whether anything changed

in the shared bundle.

• Quiet sync repairs Windows state. A profile left with

/home/user/.ssh/id_rsa is rewritten to the receiving device's local

.ssh path and the synchronized private/public key is materialized there.

• Shared storage stays untouched when it is already correct. The

regression test verifies that sshkeeper.sync remains byte-for-byte

unchanged during this local-only repair.

• Safety remains strict. Repair only applies to a profile already linked

to its remote server record and never overwrites a different existing local

private key.

No re-pairing or manual edit is required. Upgrade and run synchronization once.

Открыть релиз на GitHub ↗

sshkeeper v0.7.5 — repair partially migrated SSH key paths

v0.7.5 fixes one remaining cross-platform upgrade state that can occur after

syncing on v0.7.1-v0.7.4.

Fixed

• Repair a legacy profile when its key record is already portable. A sync

bundle can legitimately end up half-migrated: the key is stored as

~/.ssh/id_rsa, while an unchanged server profile still contains a path

such as /home/user/.ssh/id_rsa. Windows now recognizes that both names

refer to the same synchronized key, writes the key under the local

%USERPROFILE%\.ssh directory, and rewrites IdentityFile accordingly.

• Regression coverage for the real upgrade state. The test suite now

models an already-synced Windows client whose key record has migrated but

whose server record has not.

No database migration or re-pairing is required. Run synchronization once

after upgrading.

Открыть релиз на GitHub ↗

sshkeeper v0.7.4 — repair already-synced cross-platform SSH keys

v0.7.4 completes the key-path migration for clients that had already joined a

sync space with v0.7.0/v0.7.1 before upgrading.

Fixed

• Retry unchanged remote keys when the local file is missing. A Windows

client that previously accepted a Linux profile but could not read its

/home/.../.ssh/... identity now re-applies the existing remote key even

when the key record itself has not changed since the previous sync.

• Repair the profile in the same sync. The corresponding profile is

re-applied together with the key, so IdentityFile immediately changes to

the receiving user's local Windows path.

• Finish the shared-bundle migration. Once the key is readable locally,

the next synchronization replaces the legacy absolute key record with the

portable ~/.ssh/... form.

Validation

There is now an end-to-end regression test for the exact upgrade state:

v0.7.1-style Windows database and sync state, Linux absolute IdentityFile,

missing local key file, followed by one v0.7.4 synchronization. The test

requires the key file to be restored and the profile path to be rewritten.

Открыть релиз на GitHub ↗

sshkeeper v0.7.3 — safe migration of legacy synchronized key paths

v0.7.3 includes all Windows and portable-key fixes from v0.7.2 and adds one

upgrade safeguard for devices that already synchronized with v0.7.0/v0.7.1.

Fixed

• Existing Windows clients keep legacy key records during migration. If a

profile still points to an old Linux absolute path such as

/home/alice/.ssh/id_ed25519, the first v0.7.3 sync protects that legacy

record from being interpreted as a local deletion before the remote key can

be materialized under the Windows user's .ssh directory.

• Both the legacy absolute-path record ID and its new portable

~/.ssh/... record ID are treated as unreadable-but-existing during that

transition, so the remote key survives the merge and can be copied locally.

Upgrade

No re-pairing or database migration is required. Upgrade both sides as usual

and run synchronization once. Profiles and key files are migrated in place.

Открыть релиз на GitHub ↗