# OmnySSH: a Rust SSH manager with a desktop dashboard and a TUI on the same engine

> OmnySSH is a cross-platform SSH client and server manager built in Rust, with a Tauri desktop app and a terminal TUI sharing one core crate, live CPU, RAM and disk cards per host, a two panel SFTP browser, snippets that fan out across machines, and a one click SSH key setup that edits authorized_keys and sshd_config for you. The repository ships the key setup code path in the open, and the README asks you to read it before pointing it at production.

**timhartmann7/omnyssh** — Fast, open-source SSH client and server manager for macOS, Windows and Linux. Desktop GUI and terminal TUI with a live metrics dashboard, tabbed terminal, SFTP file manager, port forwarding, one-click SSH keys and snippets. Built in Rust.

- Repository: https://github.com/timhartmann7/omnyssh
- Stars: 1,229 · Forks: 69
- Language: Rust
- License: Apache-2.0
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/timhartmann7-omnyssh

## One engine, two frontends, and why the TUI still exists

OmnySSH is a fast, open-source SSH client and server manager for macOS, Windows and Linux, built in Rust, and the topic tags name the stack: tauri for the desktop app, and the primary language is Rust with an Apache-2.0 licence.

The architecture is described in the TUI section and it is the most important structural fact about the project. OmnySSH started in the terminal, and the TUI is still here, still maintained, still gets releases. Same engine underneath: the repo is a cargo workspace where crates/omnyssh-core holds the logic and the frontends sit on top.

The Cargo.toml confirms it. The workspace has three members, crates/omnyssh-core, crates/omnyssh and crates/omnyssh-gui, and there is a comment explaining why the GUI is excluded from bare cargo builds: cargo build, test and install at the root build core and TUI only, with no Tauri or npm toolchain. That is a thoughtful decision, because a Rust developer who wants the terminal version should not have to install Node.js to get it.

The TUI is published on crates.io as omnyssh and has three installation routes:

```bash
# cargo
cargo install omnyssh

# homebrew
brew install timhartmann7/tap/omnyssh

# nix
nix run github:timhartmann7/omnyssh
```

You then run omny. The key bindings are listed: press a to add a host, / to search, g to group by tag, ? for help, and Shift+K to set up keys on the selected host. The TUI has four themes, default, dracula, nord and gruvbox, and remappable keys in config.toml. Prebuilt binaries for Linux, macOS, Windows and Termux live on the releases page.

For the desktop app, the install is a single command on macOS and Linux:

```bash
curl -fsSL https://raw.githubusercontent.com/timhartmann7/omnyssh/main/install.sh | sh
```

The script detects your OS and architecture and installs the latest desktop build, into /Applications on macOS and your app menu on Linux. You can ask for the terminal app instead, or both, with curl piped to sh with the --tui or --both argument, or grab the file for your platform from the releases. The artefacts are named by target, with OmnySSH-aarch64-apple-darwin.dmg for macOS Apple Silicon, OmnySSH-x86_64-apple-darwin.dmg for macOS Intel, OmnySSH-x86_64.AppImage, .deb and .rpm for Linux x86_64, and OmnySSH-x86_64-setup.exe for Windows x86_64.

The release history is active, with v1.1.5 on 2026-10-09, v1.1.4 on 2026-09-28 and v1.1.3 on 2026-09-27, and the last push was on 2026-10-09. The repository is not archived, and it carries a CHANGELOG.md, a CONTRIBUTING.md, a flake.nix and flake.lock, an install.sh and a scripts/ directory.

## The dashboard, and what the memory comparison is actually measuring

The dashboard is the feature that distinguishes this from a terminal multiplexer, and the description is specific about what each card holds.

You add a server once. After that it sits on the dashboard as a card with live CPU, RAM and disk, uptime, distro, the top processes eating your CPU, and a badge for what runs on it. Bars turn yellow, then red, so a sick server is obvious from across the room. You can group the grid by tag, sort it, and in the desktop app drag cards into your own order.

That last set of details is what makes it a dashboard rather than a status list. Tag grouping is how you work with ten servers, and drag-to-reorder is how you make the grid match how you think about the estate, whether that is by environment, by team or by what is on fire.

The Docker badge is a small thing with a large audience. Showing how many containers are up, at a glance, on every host, is the kind of information that people end up building a script for, and it being in the card is a real time saver for the homelab and self-hosting case the topic tags name.

The comparison table is where the project makes its marketing claim, and the numbers come with the conditions stated. Memory and CPU measured on an M4 Mac with both apps open and idle. OmnySSH at about 130 MB of RAM at idle across 4 processes, Termius at about 649 MB across 9 processes, and tmux plus ssh at tiny across 1 process. The Small section puts the same figures in prose: around 130 MB of RAM with several sessions open, on a 20 MB download, while Termius on the same machine, doing nothing, sat at 649 MB across nine processes.

The table is honest about what it does not cover. tmux stays in the table because it is what most of us actually use. It wins on weight and loses on everything visual, and the table gives tmux a check for open source and free price while marking the live metrics dashboard, the two panel SFTP, snippets and broadcast, and the one click key setup as absent. It also gives Termius and omnyssh a check for account required, telemetry and open source, with omnyssh marked as not requiring an account and not doing telemetry, and Termius as requiring both. The price row has Termius as money and both others as free.

One caveat on the measurement: it is a single machine, a single configuration, and the number of sessions is not varied. It is a fair comparison on its own terms and it is not a general claim about performance.

## The one click key setup, and the code path the project tells you to read

The SSH key setup is the feature with real consequences, and the project handles it unusually well for an application that edits your server configuration.

The problem it addresses is stated plainly: password auth on a fresh VPS is the thing you always mean to fix and never do. OmnySSH does it in one click.

The flow is worth walking through, because the order of operations is the safety property. You pick a host you added yourself that has no key configured, you hit Set up SSH key, and the app generates an Ed25519 key, appends the public half to authorized_keys, and switches the host over to key auth. It then opens a fresh connection with the new key to prove the key works, and only after that does it turn password login off.

So the order is: add the key, verify you can still get in, and only then remove the old way in. That is the correct order and the fact that the documentation describes it in that order is a good sign.

The failure handling is equally explicit. Before touching sshd_config it saves a backup on the server. If any step fails, it restores the backup and leaves your access exactly as it was. Your private key never leaves your machine, and nothing gets sent anywhere except the server you chose.

And then the instruction that makes this an open source project rather than a convenience tool: the code lives in crates/omnyssh-core/src/ssh/key_setup.rs, read it before you point this at production, and the documentation says that is the whole point of shipping it open source.

One behaviour to be aware of, and the documentation is honest about it: there is no confirmation step in between, starting the flow means going through with it. That is a deliberate choice for a one click feature, and it is a real consideration if you are pointing it at a production host.

Passphrase handling is described in the same detail. Keys with a passphrase work too. When a key is encrypted, OmnySSH asks for its passphrase once and keeps it in memory until you quit, and it is never written to disk. On macOS and Linux, a key already loaded in ssh-agent is used without asking. The documentation also disambiguates a term that is easy to misread: the host Password field is the server login password, not a key passphrase.

The rest of the feature set follows the same pattern of being concrete. Full PTY sessions in tabs, switchable from the sidebar, kept running while you work in the dashboard. A two panel SFTP browser, local on the left and remote on the right, where you tick files and folders and move them across, drag them from one side to the other or straight from your file manager onto the server, with a progress bar, multi select, and the last changed time of each file. The remark about nobody remembering scp -r syntax anyway is the right justification for shipping the thing at all.

Snippets save the commands you paste every week. You pick a snippet, tick the hosts to send it to, and it runs on all of them at once. Snippets take parameters, so sudo systemctl restart {{service}} asks you for the name. Search is a command palette: hit the key combination and start typing, and you get every host you have plus every session already open, and Enter drops you into a terminal on the host you picked or back into the session you left.

And streamer mode swaps every real IP on screen for a fake one, so you can record a demo or share your screen without leaking client infrastructure. That is a small feature with a clear audience in the technical content space.

## The features that are about moving files and running commands

Beyond the dashboard and the terminals, there are three features that are about doing the work, and each of them replaces something people complain about.

The two panel SFTP browser is the first. Local on the left and remote on the right. You tick the files and folders you want and move them across, or just drag them from one side to the other, or straight from your file manager onto the server. You watch the progress bar, select many at once, and see when each file was last changed. The documentation's own justification is the right one: nobody remembers scp -r syntax anyway.

Straight from your file manager onto the server is the detail that makes it feel native rather than embedded, because a drag from Finder or Explorer onto a pane is the interaction you already have, not a new file picker dialog.

Snippets are the second. You save the commands you paste every week. You pick a snippet, tick the hosts to send it to, and it runs on all of them at once. Snippets take parameters, so the template for restarting a service asks you for the name.

The broadcast behaviour is what separates this from a clipboard manager. A snippet that runs on five machines in one action is a different tool from a snippet that copies text, and the tick-the-hosts interface is what makes the difference concrete rather than a setting buried in a menu.

Search is the third, and it is a command palette. Hit the shortcut and start typing, and you get every host you have, plus every session already open. Enter drops you into a terminal on the host you picked, or back into the session you left. The second part is the useful one, because the sessions are kept running while you work in the dashboard, so losing track of which terminal was on which machine is the problem this solves.

Streamer mode is a small feature with a clear audience. It swaps every real IP on screen for a fake one, so you can record a demo or share your screen without leaking client infrastructure. For someone who publishes terminal recordings of their homelab, that is a real risk closed rather than a cosmetic option, and it is the kind of feature that only gets built by someone who has had the problem.

Themes and sizing come next, and they are deliberately unremarkable. Light and dark both ship in the app, switchable from the sidebar, and the editor side has editor theming with customizable colour palettes.

So the feature set breaks into three groups: seeing what is happening, the dashboard; getting into a machine, the terminals and search; and doing the work, SFTP, snippets and key setup. The first group is what a screenshot of the project shows, and the last two are what you would actually miss the tool for.

## The dependency list, the release profile, and what is not in the repository

The Cargo.toml workspace is a good way to see what this application is made of and, just as usefully, what it deliberately avoids.

The workspace dependencies are tokio with an explicit feature list, and the comment explains why: explicit features only, avoids pulling in unused tokio subsystems. The listed features are macros, rt-multi-thread, time, sync, process, fs and io-util, which covers the async runtime, the timer that drives the metrics refresh, the process spawning for remote commands and the filesystem access for SFTP. There is no networking crate in the list, which tells you the SSH transport is implemented on top of the async primitives rather than pulling in a general purpose client library.

The rest are small and conventional: serde with derive, toml 0.8 for the config file, anyhow and thiserror for the two error styles, tracing for instrumentation, dirs for platform directories, and chrono for timestamps.

The release profile is tuned, and the settings say what kind of binary this is. opt-level 3, lto true, codegen-units 1, and strip true. The single codegen unit and the full LTO are the two settings that cost build time and buy runtime and binary size, which is consistent with a project whose headline claim is a 20 MB download.

The workspace package metadata sets version 1.1.5, edition 2021, rust-version 1.89, and the Apache-2.0 licence, with the repository pointing at the GitHub URL. The rust-version floor of 1.89 is worth noting for anyone on an older toolchain, and it is the kind of requirement that is easiest to miss and then blocks a build.

What is not in the repository is the front end. The GUI is a Tauri application, and the workspace comment mentions the Tauri and npm toolchain, so there is a node build somewhere in the tree, likely under crates/omnyssh-gui. The repository listing shows crates/, assets/, doc/, scripts/, a flake.nix with a flake.lock, install.sh and a Cargo.lock.

The doc/ directory and the CHANGELOG.md and CONTRIBUTING.md are the parts to read first if you are tracking releases, and the install.sh at the root is the script the one line install runs.

One last observation about the project's shape. The README's navigation bar includes a Telegram entry under the dev notes, and the topics include homelab, devops, sysadmin, server-monitoring and ssh-manager. So the audience is an individual operator with a personal fleet rather than a platform team with a fleet of thousands, and the feature choices follow from that: a dashboard of ten cards rather than a fleet view, snippets broadcast to the handful of machines you own, and a key setup flow that assumes you know which host you are pointing it at.

## Conclusion

OmnySSH fits a sysadmin or homelab operator who juggles a handful of servers and wants a dashboard and an SFTP browser instead of a terminal multiplexer, and who is comfortable with an application that edits sshd_config on their behalf. It is the wrong tool if you need audited, reproducible access management across a fleet, since the key setup is an interactive flow with a local backup rather than a declarative configuration, and the wrong choice if you want a product with a support contract. Before adopting, read crates/omnyssh-core/src/ssh/key_setup.rs, as the project asks, and decide whether you want the desktop app or the TUI, since the install script can give you either or both.

## FAQ

### How do I install OmnySSH?

On macOS and Linux the desktop app installs with curl -fsSL https://raw.githubusercontent.com/timhartmann7/omnyssh/main/install.sh | sh, which detects your OS and architecture. Pass --tui or --both to get the terminal app instead, or download the platform file from the releases. The TUI alone is available through cargo install omnyssh, brew install timhartmann7/tap/omnyssh, or nix run github:timhartmann7/omnyssh.

### What does the OmnySSH one click SSH key setup do to my server?

It generates an Ed25519 key, appends the public half to authorized_keys, switches the host to key auth, then opens a fresh connection with the new key to prove it works before turning password login off. It backs up sshd_config on the server first and restores it if any step fails, and your private key never leaves your machine.

### Does OmnySSH require an account or send telemetry?

No. The README states no account, no login screen and no telemetry, and the app opens with an empty dashboard and reads your existing ~/.ssh/config if you have one, including hosts behind a bastion through ProxyJump. The comparison table marks account required and telemetry as absent for OmnySSH.

### How do the OmnySSH desktop app and TUI relate to each other?

They share one engine. The repository is a cargo workspace where crates/omnyssh-core holds the logic and the frontends sit on top, with crates/omnyssh for the TUI and crates/omnyssh-gui for the desktop app. The GUI is excluded from the default members so that a bare cargo build or install at the root builds the core and the TUI without needing the Tauri and npm toolchain.

## Sources

- [Issues](https://github.com/timhartmann7/omnyssh/issues)
- [License: Apache-2.0](https://github.com/timhartmann7/omnyssh/blob/main/LICENSE)
- [README](https://github.com/timhartmann7/omnyssh/blob/main/README.md)
- [Releases](https://github.com/timhartmann7/omnyssh/releases)
- [timhartmann7/omnyssh on GitHub](https://github.com/timhartmann7/omnyssh)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/timhartmann7-omnyssh