OmnySSH: Your Servers, One Window, Fewer Tabs

Managing one server over SSH is pleasantly simple. Managing five is still fine. Somewhere after that, terminal tabs begin reproducing, hostnames become a memory exercise, and the command in your clipboard is always intended for a server other than the one currently accepting keyboard input.

Plenty of experienced administrators remain perfectly happy with ~/.ssh/config, ssh, tmux, and a carefully developed fear of the Enter key. Those tools are reliable, scriptable, and available almost everywhere.

OmnySSH does not try to replace that workflow. It puts a useful interface around it: a live overview of every server, full terminal sessions, SFTP, reusable commands, SSH tunnels, and key setup in one open-source application.

For somebody maintaining several dedicated servers, lab machines, or NVMe VDS instances, that can remove a surprising amount of daily friction.

Two interfaces, one SSH manager

OmnySSH is written in Rust and comes in two forms. The desktop application uses a graphical interface, while the TUI version runs entirely inside a terminal. Both use the same core engine and offer the same basic model: add or import hosts, see their status, and open the tool you need without rebuilding the connection details each time.

The desktop application is available for Apple Silicon and Intel Macs, Linux x86-64 as AppImage, DEB, or RPM, and Windows x86-64. Prebuilt TUI releases cover Linux, macOS, Windows, and Termux. The TUI can also be installed through Cargo, Homebrew, or Nix.

OmnySSH does not require an account, cloud login, or subscription. According to the project, it includes no telemetry. On first launch it can read hosts from the existing ~/.ssh/config, including IdentityFile, IdentitiesOnly, LocalForward, and hosts reached through a ProxyJump bastion. It does not rewrite that file.

This is a good design choice. A tool for organizing SSH should work with the configuration you already trust, not demand that the whole infrastructure be re-entered into somebody else’s cloud dashboard before showing the first terminal.

The dashboard answers “which server is unhappy?”

Each configured host appears as a card with current CPU, memory, disk use, uptime, operating-system information, load, and the busiest processes. If Docker is present, the card also shows how many containers are running. Hosts can be tagged, grouped, sorted, or arranged manually.

The result is not a replacement for Prometheus, Zabbix, Grafana, or a proper alerting system. OmnySSH collects a practical live summary over SSH while the application is running. It does not promise years of metrics, capacity planning, escalation policies, or a phone call when a disk fills at 04:00.

What it provides is a fast answer when you sit down to work: which machines are online, which one is short on disk, which one is busy, and where those suspiciously enthusiastic CPU bars are coming from.

One click opens a real PTY terminal in a tab. Multiple sessions remain open while you move between the dashboard, files, and other hosts. Fuzzy search and the command palette make this increasingly useful as the server list grows.

There is also a streamer mode that replaces real IP addresses on screen with fake ones. Anyone who has shared a screen and noticed a customer address in the recording five minutes later will understand why this deserves to be a feature rather than an afterthought.

SFTP without remembering which way scp goes

OmnySSH includes a two-panel SFTP manager: local files on one side, remote files on the other. It supports multiple selections, complete folders, drag and drop in the desktop app, timestamps, permissions, progress reporting, and cancellation.

None of this is revolutionary. That is precisely why it is useful. Uploading a configuration, downloading a log archive, or moving a folder should not require opening a separate client and entering the same hostname again.

Administrators who prefer rsync, scp, or sftp can continue using them. OmnySSH simply makes the occasional interactive transfer less ceremonial.

Snippets are where convenience becomes power

Repeated commands can be saved as snippets and run on one or several selected hosts. Snippets support parameters, so a command such as:

sudo systemctl restart {{service}}

asks for the service name when it runs. This is convenient for checking updates, inspecting logs, restarting the same component across a small group, or applying one carefully reviewed command to several similar VDS instances.

The important words are carefully reviewed. A broadcast command distributes mistakes just as efficiently as maintenance. Tags help organize hosts, but they do not turn a destructive shell command into configuration management.

For repeatable infrastructure changes, tools such as Ansible, Salt, or another declarative system remain the better choice. OmnySSH snippets fit the space between typing the same command six times and building a complete automation role for a one-off check.

Tunnels and bastion hosts are built in

OmnySSH supports local SSH port forwarding, equivalent to ssh -L. A database, internal dashboard, or administration interface listening only on the remote loopback address can be exposed on a local port for the duration of the tunnel.

Forward definitions can be added in OmnySSH or imported from LocalForward entries in ~/.ssh/config. Several forwards can share one connection, tunnels can reconnect after a dropped link, and hosts behind ProxyJump work as expected.

At the time of writing, remote forwarding equivalent to ssh -R and dynamic SOCKS forwarding equivalent to ssh -D are not included. SSH agent forwarding is available on macOS and Linux for terminal sessions, but it is deliberately disabled until enabled for a specific host. As always, agent forwarding should be used only with servers you trust: root on the remote host may be able to use the forwarded agent while the session is open.

One-click SSH keys, with an appropriately large asterisk

Fresh VDS installations often begin with password access, followed by the intention to configure keys “in a minute.” OmnySSH can automate that transition.

Its key setup generates an Ed25519 key, adds the public key to authorized_keys, and tests a fresh connection. It backs up the server’s SSH configuration and can disable password login only after key authentication succeeds.

The private key remains on the local machine. Passphrases for encrypted keys are kept in memory for the session rather than written to disk, and existing ssh-agent keys are supported on macOS and Linux.

This is thoughtful automation, but it still changes authentication on the server. Read the confirmation dialog, verify the host, and make sure the provider’s VNC, BMC, or other out-of-band console is available before changing SSH settings. Test the workflow on a new system before pointing it at an old production server with a creative PAM configuration and twelve years of history.

The project’s documentation invites users to inspect the key-setup source code before using it in production. That is one of the nicer consequences of an Apache-2.0 licensed tool: the dangerous button is not a black box.

Security still depends on the version

OmnySSH checks SSH host keys through the usual known_hosts mechanism. That matters because the host key is what tells the client it reached the same server as before rather than a machine impersonating it.

Use version 1.1.5 or newer. The 1.1.5 changelog documents an important fix: older builds could accept a different type of host key when the stored key type was no longer offered. The release also fixed terminal escape sequences supplied through remote filenames or process names.

This is not a reason to avoid the project. It is a reason to treat an SSH manager like any other security-sensitive client: keep it updated, read release notes, verify downloaded packages, and investigate host-key warnings instead of deleting them until the red message goes away.

The project is active and has attracted a growing community, but it is still young. Test it with the authentication methods, bastions, legacy devices, shells, and operating systems you actually use before making it the only path into production.

Installing OmnySSH

The project offers a convenience installer for the desktop application on macOS and Linux:

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

Piping a remote script into a shell is convenient, but administrators may reasonably prefer to inspect install.sh first or download a package from the OmnySSH releases page. Windows users can download the installer there as well.

For the terminal interface, Homebrew users can run:

brew install timhartmann7/tap/omnyssh
omny

Cargo and Nix installation options are documented in the repository. The desktop and TUI applications share the same purpose, so the choice is mostly whether you want native windows and drag-and-drop or prefer never to leave the terminal.

A good companion for a growing VDS collection

An ITLDC NVMe VDS can be ordered quickly, and a few minutes later there is another IP address, another SSH host key, and another machine that somebody has to remember exists. One server becomes a VPN endpoint, another runs monitoring, a third hosts a development environment, and suddenly “a couple of VDS instances” has become infrastructure.

OmnySSH is particularly comfortable at that scale. It is simpler than deploying a full management platform, but far more informative than a folder of terminal profiles. Tags can separate production, development, backup, and personal systems. The dashboard gives a quick health check, snippets handle small repeated jobs, and SFTP and tunnels are available without switching applications.

It also requires no agent on the managed server. If the machine already accepts SSH and provides the usual Unix utilities, OmnySSH can gather its summary and open sessions. That makes it suitable for existing servers as well as new VDS instances, without installing another permanent service on every host.

OmnySSH will not replace monitoring, configuration management, backups, or the ability to use plain ssh when the friendly interface is unavailable. It does something more modest and very useful: it makes a collection of servers easier to see and less annoying to operate.

For anyone whose terminal tab bar has become a tiny, unreadable inventory system, that may be reason enough to try it.