# trzsz-ssh (tssh): a drop-in OpenSSH client with a login prompt, batch login and UDP mode

> tssh reimplements the openssh client in Go and adds a host picker, remembered passwords, trzsz and zmodem transfers, and a mosh-like UDP mode through tsshd. The compatibility table is long; the parts that need a server-side helper are where adoption gets complicated.

**trzsz/trzsz-ssh** — trzsz-ssh ( tssh ) is an ssh client designed as a drop-in replacement for the openssh client. It aims to provide complete compatibility with openssh, mirroring all its features, while also offering additional useful features. Such as login prompt, batch login, remember password, automated interaction, trzsz, zmodem(rz/sz), udp mode like mosh, etc.

- Repository: https://github.com/trzsz/trzsz-ssh
- Website: https://trzsz.github.io/tssh
- Stars: 2,729 · Forks: 156
- Language: Go
- License: MIT
- Published: 2026-09-28 · Updated: 2026-09-28 · Language: en
- Canonical page: https://hysenlabs.com/projects/trzsz-trzsz-ssh

## What tssh replaces, and who feels the pain

The openssh client is the reference implementation, and its configuration language is the de facto standard for describing hosts. That is also its limit. There is no host picker when you forget an alias, no way to log into twenty machines at once, and no built-in file transfer over the same session. People work around this with shell aliases, expect scripts, or a wrapper that reads ~/.ssh/config and prints a menu. tssh is that wrapper, written as a full client rather than a script.

The audience is narrow and specific: engineers who manage many hosts, keep their inventory in ~/.ssh/config, and want the extras without switching config formats. The README frames it as a drop-in replacement for the openssh client that aims at complete compatibility while adding features openssh does not have. If you do not already have a config file worth keeping, the value proposition shrinks considerably.

## How the compatibility layer and the extra features fit together

The repository layout is a Go module with cmd/, internal/ and tssh/ directories, and go.mod names the dependencies that do the work. Two of them are telling. github.com/trzsz/ssh_config is the parser for the openssh configuration format, so tssh reads the same files rather than defining its own. github.com/trzsz/trzsz-go and github.com/trzsz/tsshd are the transfer protocol and the server-side helper for the UDP mode. The TUI is built on charm.land/bubbletea/v2, bubbles and lipgloss, which is where the login prompt and theme come from.

The README's compatibility table lists the option groups that are implemented: pseudo TTY flags (-t, -T, RequestTTY), algorithm selection (Ciphers, KexAlgorithms), proxy support (-J, -W, ProxyJump, ProxyCommand), multiplexing (-M, -S, -O, ControlMaster, ControlPath, ControlPersist), agent forwarding, X11 forwarding, known-hosts handling, and port forwarding in all three directions (-L, -R, -D). That is a deliberate design choice: reimplement the surface area rather than shell out to ssh. The cost is that every openssh behavior has to be reproduced in Go, and the README does not claim bit-for-bit parity, only that it mirrors the features.

The extra features sit on top of that base. Login prompt and custom theme are presentation. Batch login and group labels are inventory management. Remember password and automated interaction are convenience. Trzsz (trz/tsz), zmodem (rz/sz) and scp/sftp support are transfer paths. Reconnect mode and UDP mode are the network-resilience story, and the README ties both to tsshd, describing intermittent connectivity, roaming and high-latency links such as cellular data and unstable Wi-Fi.

## Building tssh from source and taking it for a first run

The README does not spell out an install procedure; it links to the release page and the project website at trzsz.github.io/tssh. What the repository does give you is a Makefile with three targets, and the build target is plain go build. The Makefile writes the binary into ./bin, and on Windows it expects tssh.exe.

Running make with no arguments builds ./bin/tssh from ./cmd/tssh.

```bash
make
```

There is an install target that copies the binary to /usr/bin, and the Makefile explicitly prints that install is not supported for Windows.

```bash
make install
```

Test execution is also wired up through the test target.

```bash
make test
```

Once the binary exists, the intended first use is the login prompt. The README describes tssh as reading the same configuration as openssh, so existing Host entries should be picked up without conversion, and the prompt lists them for selection. The README's feature list also includes a custom configuration section and support for comments inside the config, which matters if your file is full of commented-out hosts. For a first real run, invoke the binary the way you would invoke ssh, then check that the host list matches the Host blocks you expect before relying on batch login or remembered passwords.

## The UDP mode depends on tsshd, and that is the real constraint

The headline resilience feature is not self-contained. The README states that tssh with tsshd supports intermittent connectivity, roaming, and use on high-latency links. tsshd is a separate repository, and go.mod pins it as a dependency, but a dependency in the client does not install anything on the remote host. If you want the mosh-like behavior, you need tsshd running on the other side, and the README does not describe a fallback path that gives you the same roaming behavior over plain TCP.

That changes the adoption calculus. On hosts you control, it is a deployment step. On shared infrastructure, jump boxes, or customer environments where you cannot install a daemon, the UDP mode is simply unavailable, and you are using tssh as an openssh-compatible client with a nicer prompt. The reconnect mode is described alongside UDP mode in the feature table, and the same server-side question applies to it. This is the kind of trade-off the README presents as a capability rather than a prerequisite, and it is worth reading the tsshd repository before promising anyone a roaming SSH session.

## Where tssh is the wrong tool

The compatibility table is the selling point and the risk. A reimplementation in Go will track openssh behavior only as far as its authors have implemented it, and the README lists supported option groups rather than asserting that every corner case behaves identically. If your environment depends on an option group outside that table, or on a subtle interaction between options, you are relying on untested ground. The README does not document a rollback path or a compatibility test suite, so there is no published way to check before you switch.

There is also the packaging question. The repository contains a Makefile and a release page, not a package-manager recipe. The repository does contain a debian/ directory, which suggests Debian packaging work exists in-tree, but the README does not describe installing from apt. Teams that require a signed distribution package from their OS vendor will need to verify that path themselves. And if your workflow is a handful of hosts and a config file you rarely edit, the login prompt and batch login solve a problem you do not have; the extra surface area is not free.

## How it differs from mosh and from keeping plain openssh

Mosh solves the roaming problem by running a separate protocol over UDP and keeping the session alive through IP changes. tssh takes a different route: it stays an SSH client first, reading the openssh configuration format and implementing the openssh option groups, then adds a UDP mode that requires tsshd on the remote side. The practical difference is that mosh replaces your client, while tssh tries to replace it while remaining compatible with what you already have. If your config file is the center of your workflow, that distinction matters more than the protocol details.

The other comparison is doing nothing. Plain openssh plus a shell function that greps ~/.ssh/config gives you a crude host picker, and scp or rsync covers transfers. tssh's advantage over that is a maintained implementation with a theme, group labels, remembered passwords and a transfer protocol, all reading the same config. Its disadvantage is that it is a young client with a version number in the v0.1.x range, and the compatibility claims are the project's own.

## Maintenance, licensing and what an upgrade costs

The project is not archived, and the last push to main was on 2026-09-12. The most recent tagged release in the repository is v0.1.26 from 2026-07-26, with v0.1.25 before it in May, and a dev build published alongside the September push. That cadence suggests ongoing work, but the version numbers are still in the 0.1 range, so treat the interface as pre-1.0: configuration keys and flags can move between releases.

The licence is MIT, which is permissive and places few obligations on how you redistribute or modify the binary. That is a statement about the licence text, not legal advice; if you ship tssh inside a product, read the LICENSE file in the repository rather than this paragraph. The upgrade cost is mostly the Go toolchain: go.mod requires Go 1.26.0, so a build on an older toolchain will fail before it reaches any tssh code. Upgrading also pulls the pinned trzsz-go and tsshd revisions, which means a client upgrade can change transfer or UDP behavior even when the tssh source itself looks unchanged.

## Conclusion

Adopt tssh if you already live in ~/.ssh/config, want a host picker and batch login without giving up openssh flags, and can accept that UDP mode requires tsshd on the remote side. Do not adopt it if you need a client that is not a single Go binary, or if you cannot build it yourself, since the README points at the release page and the website rather than giving package-manager instructions. Before rolling it out, verify three things: that your existing config parses under the bundled ssh_config library, that your remote hosts either have tsshd installed or you are content with plain TCP, and that the dev build or v0.1.26 binary matches the platform you run.

## FAQ

### What is trzsz-ssh (tssh)?

It is an SSH client written in Go that is designed as a drop-in replacement for the openssh client. The README says it aims for complete compatibility with openssh while adding features such as a login prompt, batch login, remembered passwords, trzsz and zmodem transfers, and a UDP mode through tsshd.

### How do I install tssh?

The README points to the release page and the project website rather than giving install steps. The repository Makefile has an install target that copies the built binary to /usr/bin, and the Makefile states that install is not supported on Windows.

### Does tssh need tsshd for the UDP mode?

Yes. The README states that tssh with tsshd supports intermittent connectivity, roaming and high-latency links such as cellular data and unstable Wi-Fi. tsshd is a separate repository, so the remote host needs it installed for that mode to work.

### What licence does trzsz-ssh use?

The repository contains a LICENSE file and the README badges identify it as MIT. That is the licence identifier stated by the project.

## Sources

- [License: MIT](https://github.com/trzsz/trzsz-ssh/blob/main/LICENSE)
- [Project website](https://trzsz.github.io/tssh)
- [README](https://github.com/trzsz/trzsz-ssh/blob/main/README.md)
- [Releases](https://github.com/trzsz/trzsz-ssh/releases)
- [trzsz/trzsz-ssh on GitHub](https://github.com/trzsz/trzsz-ssh)

---

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