RustConn: one window for SSH, RDP, VNC, Kubernetes and Zero Trust

One orchestrator over nine kinds of remote target

RustConn is described as a cross-platform connection orchestrator with a GTK4 and libadwaita interface, and that word orchestrator is doing real work. The project brings SSH, RDP, VNC, SPICE, MOSH, Telnet, Serial, Kubernetes and Zero Trust connections under one roof, with embedded Rust clients where possible and integration with external tools where needed. It runs on Linux with GTK4 and libadwaita, on macOS, on FreeBSD, and on Windows via WSLg.

The protocol table is where the design shows. SSH runs in a VTE terminal with port forwarding through -L, -R and -D. RDP uses IronRDP with a FreeRDP fallback, and the fallback is bundled in the Flatpak. VNC uses vnc-rs with a vncviewer fallback. SPICE is external through remote-viewer or virt-viewer. Telnet is a VTE terminal. Serial is picocom through VTE. Kubernetes is kubectl exec through VTE. MOSH is mosh through VTE.

The Zero Trust row is the broadest: AWS SSM, GCP IAP, Azure Bastion, Azure SSH with AAD, OCI, Cloudflare, Teleport, Tailscale, Boundary and Hoop.dev are all listed as external clients. And the Web row offers an embedded WebKitGTK 6.0 browser on Linux, the system browser, or a custom browser command.

So the value is not that RustConn reimplements every protocol. It is that the session list, the credentials, the jump host settings and the window management are shared, while the actual transport is either a Rust client in the process or a process it launches.

The primary language is Rust, the licence is GPL-3.0, and the project is published under the name io.github.totoshko88.RustConn on Flathub, with Snapcraft, the AUR, openSUSE and the FreeBSD ports also linked from the README.

A Rust workspace split along system boundaries

The repository layout mirrors that embedded-or-external split, and the Cargo workspace makes the boundaries explicit:

[workspace]
resolver = "2"
members = [
    "rustconn-core",
    "rustconn",
    "rustconn-cli",
    "rustconn-pty-sys",
    "rustconn-locale-sys",
    "rustconn-env-sys",
    "rustconn-dock-sys",
]

Seven members, and the naming tells you what each one is for. `rustconn-core` holds the shared domain logic, `rustconn` is the GTK4 application, and `rustconn-cli` is the headless command line tool. The four `-sys` crates are the platform bindings: `rustconn-pty-sys` for pseudo terminals, `rustconn-locale-sys` for translation, `rustconn-env-sys` for environment and process handling, and `rustconn-dock-sys` for desktop integration such as the dock.

The shared dependency list in the workspace manifest is where the asynchronous design becomes visible. tokio is declared with an explicitly enumerated feature set, and the comments explain why: Cargo unifies tokio features across all crates, so listing the real set drops unused features and trims tokio's own compile, and the manifest says to verify with `cargo build` after changing it. The enabled features are rt-multi-thread, macros, net, time, sync, fs, process and io-util, with each one annotated by what uses it, from `tokio::select!` in the debounce worker to `tokio::process::Command` for CLI downloads and secret backends.

The GTK side is gtk4 at 0.11 and vte4 at 0.10, and the comment on the vte4 dependency explains the version floor: v1_5 is the baseline because Ubuntu 24.04 with libadwaita 1.5.0 and the snap's core24 platform are still supported build targets, with an opt-in feature for libadwaita 1.6 and newer.

For the GTK baseline, the manifest sets the edition to 2024, the rust-version to 1.95, and the version to 0.23.16, matching the release tag. It also carries a deny.toml for dependency policy, typos.toml, rustfmt.toml and .clippy.toml, so the project lints itself.

Where the terminal ends and the external client begins

The type column of the protocol table is the most useful thing in the README, because it tells you what a session actually is.

Embedded means the client is inside the RustConn process, in a VTE terminal widget for the text protocols. That gives you the terminal features listed in the capabilities table for free: split terminals, command snippets, text highlighting rules, session recording, custom terminal themes, tab overview and tab pinning. Those are GTK4/VTE features, so they apply to SSH, Telnet, Serial, Kubernetes, MOSH and Zero Trust sessions, since all of those are described as running through VTE.

External means RustConn launches a program. SPICE goes through remote-viewer or virt-viewer, and so does Serial through picocom. That distinction has a practical consequence: those sessions are not in the embedded terminal, so the terminal features do not apply to them, and the window management has to work with whatever the external client provides.

RDP and VNC are the hybrid case, marked Embedded + external, where a Rust implementation is tried and a conventional client is the fallback, and the Flatpak bundles those fallbacks. The Web row is the same shape, with an embedded WebKitGTK 6.0 browser on Linux and system browser or custom command options elsewhere.

One more thing about embedded clients is worth stating plainly. Because they are Rust implementations running in the same process as the application, they carry a different risk profile from an external binary that RustConn merely launches. A crash in an embedded client takes the application with it, and a flaw in an embedded RDP or VNC implementation is RustConn's own code to own, not a dependency's. The README does not discuss this trade-off, but it follows from the design.

Credential storage as the reason to switch

The security row is the longest in the capabilities table, and it is the part most likely to be the deciding factor in a migration.

The credential backends listed are KeePassXC with KDBX files, libsecret, the macOS Keychain, the Bitwarden CLI, the 1Password CLI, the Passbolt CLI, Pass from passwordstore.org, and script credentials. On top of that there is an encrypted-file fallback that needs no keyring at all, either machine-bound or a portable file for use across machines, plus hardware-token SSH authentication with FIDO2 security keys, PKCS#11 devices, YubiKey and smart cards, and FIDO2 passkey redirection for RDP sessions.

The list of backends is a list of alternatives, not a stack. A user picks one. That means the migration question is not which password manager to install but which one you already use, and the answer determines whether the switch is painless or a project.

The export row gives the privacy story its counterweight. RustConn can export to Asbru-CM, Remmina, SSH config, Ansible inventory, Royal TS, MobaXterm, SecureCRT, CSV, RDP files and its own native .rcn format, and it states plainly that passwords are never exported. So moving your connection list out is easy, and moving the secrets with it is not, which is exactly the design you would want and exactly the thing to be aware of when you plan an exit.

The import row is longer than the export row, and that asymmetry is worth noting. It reads Asbru-CM, Remmina, SSH config, Ansible inventory, Royal TS, MobaXterm, SecureCRT, PuTTY and KiTTY .reg files, mRemoteNG confCons.xml, Remote Desktop Manager, RDP files, virt-viewer .vv files, libvirt XML and daemon, CSV, and the native .rcn format. Fourteen importers against nine exporters, which tells you the author expected people arriving from other tools and leaving rarely.

The features that go beyond a list of saved sessions

A connection manager earns its place through the things around the connections, and RustConn's list is long enough that some deserve naming.

Networking is where the project is most opinionated. Jump hosts can be picked per connection, per group, or as a global default, and they are honoured by SSH, SFTP, RDP, VNC and SPICE, with multi-hop chains and a per-connection Direct override. There is an Open Browser via Tunnel feature, where one right-click on an SSH host raises a SOCKS proxy and opens a browser, embedded or external Chromium, routed through it to reach host-only web interfaces. Multipath TCP is supported for mobility and bandwidth aggregation across SSH, RDP and VNC, along with network-change auto-reconnect, port knocking and fwknop SPA.

Automation covers expect rules, key sequences, pre and post-connect tasks, elevated credentials through sudo or su injection, output filters using ChromaTerm, cluster and ad-hoc broadcast, session reconnect and Wake-on-LAN.

Workflow adds smart folders, SSH port forwarding, a visual SSH tunnel builder, workspace profiles that save and restore open sessions including split layout and divider ratio, settings backup and restore, and .rdp file association.

Cloud sync synchronises connections through a shared cloud directory such as Google Drive, Syncthing, Nextcloud or Dropbox, with a group sync model described as Master/Import and a simpler sync using UUID-based merge.

Two features have a specific scope. Session windows move any session, including embedded RDP, VNC and Web sessions, into its own window and back with Ctrl+Shift+M, with per-monitor fullscreen. The remote host metrics bar shows CPU, RAM, disk, network, load and system information, and it is described as agentless with a per-connection toggle, which is a meaningful distinction for a tool that otherwise runs arbitrary commands on remote hosts.

The headless CLI and the internationalisation effort

RustConn ships a command line tool, `rustconn-cli`, for headless management. The README lists listing, adding, updating and deleting connections, import and export, snippets, groups, templates, clusters, Wake-on-LAN and shell completions, with optional secret and client-launch commands behind feature flags.

That is the part of the project most likely to be useful in a script, and the fact that the secret and launch commands sit behind optional features is a good sign, since it means the default build does not carry capabilities you did not ask for.

The language list is worth a sentence of its own. English plus 17 translations: Belarusian, Czech, Danish, German, Spanish, French, Italian, Georgian, Kazakh, Dutch, Polish, Portuguese, Slovak, Swedish, Ukrainian, Uzbek and Chinese. A `po/` directory at the root and the `rustconn-locale-sys` crate in the workspace are the machinery behind it.

The packaging breadth matches the platform claims. Beyond the Flathub listing with its io.github.totoshko88.RustConn app id, the README links a Snapcraft package, the Arch User Repository, an openSUSE Build Service package and the FreeBSD ports collection. There is a `snap/` directory, a `debian/` directory, a `packaging/` directory and a `flake.nix` in the tree, and an `install-desktop.sh` script for the desktop entry.

The release cadence is fast. Tags v0.23.14, v0.23.15 and v0.23.16 landed on 2026-10-15, 2026-10-17 and 2026-10-19 respectively, the repository is not archived, and the last push was on 2026-10-19. Fast releases are good for a tool whose protocol clients track upstream libraries, and they also mean you should pin a version rather than track a branch.

Where RustConn is the wrong choice

The first limit is platform. The README says it runs on Linux with GTK4 and libadwaita, macOS, FreeBSD, and Windows via WSLg. Windows support is therefore a Linux environment, and the primary platform is the one where the GTK4 feature set is richest. A team with native macOS or Windows desktops and no Linux environment is not the target audience, and a Flathub-first distribution with Snap, AUR, OBS and FreeBSD ports shows where the real usage is.

The second limit is the external client dependency. Six of the protocol rows are external only, including every Zero Trust backend. RustConn will not work for you if the machine does not already have remote-viewer, virt-viewer, picocom, mosh, kubectl or the CLI for your Zero Trust provider installed and configured. The README's phrasing is that it integrates with external tools where needed, which is honest, but it does mean the tool is a front end to a collection of tools rather than a replacement for them.

The third is the scale of the surface. The capabilities table has ten rows and the security row alone lists eight credential backends, two hardware token standards and an encrypted file fallback. A tool with that many options has a configuration surface to match, and the README does not describe a per-connection override model beyond the ones it names, nor does it document what happens when two credential backends are configured at once.

The fourth is the version floor. The manifest asks for rust-version 1.95 and edition 2024, so building from source needs a current toolchain, and the GTK dependency floor is pinned for the sake of Ubuntu 24.04 and the core24 snap platform rather than for the newest libraries.

The alternative is the one this tool is positioned against: keeping separate native clients, an SSH terminal, an RDP client and a Kubernetes tool, and living with the credential duplication. The difference in approach is that RustConn centralises session state and credentials across protocols at the cost of embedding some protocol implementations in one process. For a sysadmin with forty hosts of mixed types, that centralisation is the whole value. For someone who uses one protocol on one host type, it is a heavier install with nothing to gain.

Editorial conclusion

Adopt RustConn when you juggle many remote targets across protocols and want one credential store, one session list and one window instead of five separate tools, especially if you already work in GTK4 on Linux. Do not adopt it if you need a native macOS or Windows application rather than a Linux build running through WSLg, or if you want every protocol handled by an embedded client, since SPICE, MOSH, Serial, Kubernetes and the whole Zero Trust row are all external. Before you migrate your connection list, test the import path for your existing format, since the list of supported imports is long but the fidelity of each one is not documented, and confirm your secret backend, because the KeePassXC, libsecret, Keychain and Bitwarden options are alternatives rather than a single store.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. totoshko88/RustConn on GitHub