sshs: A Rust TUI for Connecting Through SSH Config

Why sshs Uses ~/.ssh/config Instead of Maintaining a Host Database

sshs addresses the small but persistent friction of connecting to regularly used remote machines. Instead of requiring users to maintain another inventory of hosts inside sshs, the README says it uses ~/.ssh/config to list and connect to hosts. That file is already the central configuration surface for OpenSSH clients, including hostnames, usernames, ports, identity files, and proxy commands. Keeping host definitions there avoids duplicating connection settings in a second application-specific store.

The intended users are people who already use SSH from a terminal, particularly developers and system administrators who maintain several aliases. sshs is not an SSH server, key generator, credential manager, or replacement protocol client. Its only stated requirement is that ssh is installed and accessible from the terminal. That boundary matters: the project supplies a selection interface around existing SSH configuration, while the final connection still depends on the user's local ssh installation and configuration.

The approach also preserves familiar config constructs. The sample in the README includes a named host with HostName, User, and Port, plus a proxy-oriented host using ProxyCommand. The README directs readers to the OpenBSD ssh_config reference for the complete range of supported configuration syntax. That is a stronger source for connection behavior than any additional configuration model that sshs might introduce.

There is a trade-off for users who prefer scripts or shell pipelines. A TUI is designed for interactive selection, so it is less suitable when a job needs a predictable noninteractive command. The repository does not document an automation interface, scripting API, or output format for exporting the host list. For routine scripted access, invoking the relevant alias directly through ssh remains the clearer choice.

The Rust TUI Stack Behind sshs 4.8.0

The package metadata defines one executable named sshs from src/main.rs. Its release profile enables LTO, removes symbols with strip = true, and sets codegen-units = 1. Cargo.toml also identifies Rust 2021 as the edition and MIT as the package license. These details describe a compiled Rust application rather than a shell script, but the repository documentation does not provide runtime measurements or resource comparisons.

The dependency list shows the parts used to construct the terminal experience. ratatui and crossterm provide terminal rendering and terminal event or cursor handling, while tui-input is present for text input. fuzzy-matcher supports searching host names, and itertools assists with collection processing. clap provides command-line parsing, including the documented --config option's surrounding CLI layer. glob, regex, shlex, shellexpand, handlebars, serde, strum, and strum_macros round out the parsing, expansion, templating, serialization, and enumeration dependencies visible in Cargo.toml.

Based on the README and repository layout, the basic data flow begins with an SSH config selected from ~/.ssh/config or --config. sshs turns configured entries into its TUI host list, lets the user interact with that list, and connects to a selected host through the local ssh command. The documentation does not publish the internal parser types, key bindings, connection template, or exact argument passed to ssh. Those implementation details cannot be confirmed beyond the dependency and README evidence.

The project also includes an example target named demo at scripts/demo.rs and a test directory. A docker-compose.yml defines a service named sshd, exposes host port 2223 to container port 22, mounts a test public key and sshd_config, and checks availability with ssh-keyscan. This supports development against an SSH service, but the README does not describe docker-compose.yml as an end-user installation route.

Installing sshs Through Package Managers and Release Packages

Before installing, confirm that ssh is available from the terminal. The README lists Homebrew, Chocolatey, Arch Linux, Alpine Linux, Debian and Ubuntu, NetBSD, Nix, downloadable release binaries, and a source build. Package availability differs by operating system, and the Alpine entry specifically points to the testing repository.

On macOS or a system using Homebrew, install sshs with:

brew install sshs

The successful command should make the sshs executable available through the package manager's normal binary path.

On Arch Linux or Alpine Linux, the documented package commands are:

pacman -S sshs

apk add sshs

For Debian or Ubuntu on amd64, the README instructs users to download the architecture-specific package and install it with apt:

curl -LO https://github.com/quantumsheep/sshs/releases/latest/download/sshs-linux-amd64.deb
sudo apt install ./sshs-linux-amd64.deb

ARM machines use `arm64` in place of `amd64`. The Cargo package metadata declares a Debian dependency on openssh-client, matching the README's requirement that ssh be present.

NetBSD and Nix installations use different packaging commands:

pkgin install sshs

nix profile install 'github:quantumsheep/sshs'

The README also says releases contain prebuilt binaries for Linux, macOS, and Windows. It does not name individual release filenames or describe executable verification, so users following that route must consult the releases page for the correct artifact.

Building the Master Branch and Reaching a First Host Selection

A source installation requires Rust and Cargo. The README says rustup can install the required toolchain. Its direct Cargo command installs sshs from the Git repository:

cargo install --git https://github.com/quantumsheep/sshs

After installation, `~/.cargo/bin` must be present in `PATH`. The README does not show a first `sshs` command beyond documenting the application itself, but the executable name in Cargo.toml is `sshs`, so the normal launch command is:

sshs

Running it should open the terminal interface described by the README. Host selection behavior is not documented further, and there is no published list of keys for moving through entries, searching, confirming a host, or canceling. Do not assume bindings from other terminal applications; the README does not define them.

For a local build, clone the repository, build the release profile, and run the generated binary:

git clone https://github.com/quantumsheep/sshs.git
cd sshs
cargo build --release

The README places the result at./target/release/sshs. A first build compiles all dependencies and can therefore take longer than an end-user package installation, although no timing data is provided.

A usable ~/.ssh/config must also exist. If it does not, the README's troubleshooting step is:

touch ~/.ssh/config

An empty file satisfies that immediate filesystem check but does not define any hosts. Add entries before expecting sshs to present a useful selection.

ProxyJump Hosts and Alternative Config Files in sshs

The default configuration path follows the conventional ~/.ssh/config location. The README confirms that another file can be supplied with --config. This is useful when credentials or environments are separated, although the README includes no example invocation or command-line reference.

The sample config demonstrates more than a plain hostname. This entry defines a named connection with three properties:

Host "My server"
  HostName server1.example.com
  User root
  Port 22

The quoted alias is the user-facing name, while HostName identifies the network destination, User selects the account, and Port sets the service port. sshs points at OpenSSH's ssh_config documentation for complete configuration syntax, so users should consult that reference when a required field is absent from this short example.

The second named entry illustrates a connection that traverses a proxy:

Host "Go through Proxy"
  HostName server2.example.com
  User someone
  Port 22
  ProxyCommand ssh -W %h:%p proxy.example.com

This expresses connection routing through the standard SSH configuration mechanism rather than through a separate proxy form in sshs. Whether every parser feature accepted by OpenSSH is supported by sshs is not stated. That distinction is important: the README says it reads SSH config and points to ssh_config, but it does not publish a compatibility matrix.

If sshs cannot display an expected entry, the first checks supported by the documentation are the config file's existence and syntax. The README does not explain error reporting for malformed lines, duplicate aliases, unsupported options, missing keys, or unreachable hosts. Those cases require direct inspection of the configuration and testing with the configured ssh command.

Maintenance Signals, Upgrade Surface, and MIT Licensing

The repository is not archived, and its last push was on 2026-08-29. Release 4.8.0 was published on 2026-08-28, one day before that push. These are the maintenance facts available from the repository record. They show recent project activity around version 4.8.0, but the documentation does not provide a support policy, compatibility matrix, release schedule, or migration guide.

Upgrading through a package manager depends on the operating system. The Homebrew, Chocolatey, Arch, Alpine, NetBSD, and Nix instructions name package repositories, while Debian and Ubuntu use a file downloaded from the latest GitHub release. The README does not state whether those package channels deliver the same version immediately. Users managing several machines may therefore need to track the channel used on each host.

The source build tracks the repository's current code when Cargo installs from Git. The manual build creates a local executable, but no checked-in update command is documented. Upgrading that installation also means fetching newer source and rebuilding. The project does not document migration steps between 4.7.2, 4.7.1, and 4.8.0.

Cargo.toml and the repository license identify MIT licensing. That permits use, modification, distribution, and reuse under the license's conditions, subject to its notice requirements. This is a technical summary, not legal advice. For organizations, the practical adoption checks are the distribution artifact and source build, the dependency policy applied to Rust crates, and whether the internal SSH configuration review accepts the same aliases and commands used interactively.

Editorial conclusion

Developers and operators who keep multiple entries in ~/.ssh/config should evaluate sshs when a local TUI fits their terminal workflow. People who need documented noninteractive automation, remote session management, or behavior unsupported by OpenSSH configuration should use a direct ssh command instead. Verify first that ssh is on PATH, that the intended config parses correctly, and that your chosen package or release supports the required host aliases.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. quantumsheep/sshs on GitHub
4. README
5. Releases