ssheven is an SSH client for Mac OS 7 through 9, written in C for 68000 hardware

Why an SSH client for a 1990s Mac exists at all

ssheven is a minimal new SSH client for Mac OS 7, 8 and 9. The phrase new is doing work in that sentence, and the README's wording points straight at the reason. A new SSH client for a platform whose own Apple-provided tools stopped being updated decades ago is a restoration project, not a product push.

The gap it fills is concrete. The machine can run a terminal emulator, and a modern SSH client can be compiled for it, but the era's own network stack is Open Transport rather than the BSD sockets that every modern SSH library assumes. The topics list names retro68 alongside classic-mac-os and ssh-client, and the build section says the project uses Retro68, which requires the Universal headers, and that it also requires mbedtls, libssh2 and libvterm.

The last of those three is the one worth pausing on. libvterm is a terminal emulator library, and the fact that it is needed tells you the client renders a terminal in software rather than driving a real console. On a machine that predates any GPU or even modern framebuffer, that is the only way to get a usable text screen, and it is also the source of the performance complaints the README lists.

The project status line in the README states that as of 0.8.0 the client is fairly secure and usable, but without a polished UX or all planned features, and that versions prior to 1.0.0 should be considered alpha/beta quality. It also links to the GitHub releases page, so the version history is the reference point.

The hardware floor is 2MB of RAM and a floppy's worth of disk

The system requirements section is short and concrete, and it sets the scope of what this client can be.

The processor requirement is any PPC processor, or at least a 68030, with a 68040 strongly recommended. RAM is 2MB, and disk space fits on a floppy. The operating system floor is System 7.1 or later, and versions below 7.5 require the Thread Manager extension, which is the cooperative multitasking era of the platform and therefore a hard dependency for anything that needs more than one thread.

Networking is the other hard requirement. Open Transport networking is required, and the latest version possible is highly recommended. Open Transport is the transport layer abstraction Apple shipped before Mac OS X, and the reason it is called out as a version rather than just a feature is that the networking stack was revised several times and the client depends on the later behaviour.

The floppy figure is worth reading as a design constraint rather than a boast. A modern SSH client with modern crypto would not fit. So the client's size comes from choosing implementations that fit the memory budget, which is why the build pulls in Mbed TLS and libssh2 rather than OpenSSH itself.

The screenshot the README links and the box photograph in the header tell the same story from a different angle. The to-do list mentions finishing and uploading the papercraft box, the floppy sticker artwork and the icon and logo svg, so the deliverable is meant to be an object you can hold, not just a file you copy.

Building it means Retro68, cmake and three vendored libraries

The build section is where the project is most concrete, and it names its dependencies precisely.

It uses Retro68, which requires the Universal headers, and cmake. It requires mbedtls, libssh2 and libvterm, and it points at the author's own forks of those libraries for details. Those three are now pulled in as submodules, and the README states that everything should get built with a single CMake build.

The submodule arrangement is visible in the repository layout. Alongside the CMakeLists.txt there are three directories, libvterm, opentransport-libssh2 and opentransport-mbedtls, and the names tell you the story: these are forks of the upstream libraries with Open Transport support added, since upstream libssh2 and Mbed TLS speak BSD sockets and this client needs to speak Open Transport instead.

That is the crux of the whole project and it explains the effort. Porting an SSH implementation onto a pre-BSD networking stack is the work; the client itself is the thin layer on top.

The script build-ssheven.bash can be used to build a fat binary, or just as reference for build commands. A fat binary is the relevant target for classic Mac OS, where a single self-contained file on a floppy is far easier to move between machines than a folder of libraries.

The source layout follows the same shape. There is a main ssheven.c with a header, a console module handling the screen and input in ssheven-console.c, a net module in ssheven-net.c, a debug module, and a set of resource files written in the classic Mac resource format with the .r suffix, covering ssheven.r, ssheven-icons.r and ssheven-constants.r. The Unicode handling lives in its own header, ssheven-unicode.h, which is a hint at the partial support the to-do list calls out.

The known problems are honest, and they are the ones you would predict

The known problems section is unusual for a project of this size, and it is the most useful part of the README.

Drawing the screen is somewhat slow. Input latency feels high because redrawing the screen is slow, along with all the encryption, which is also slow. Receiving a large amount of data may break the channel or cause lockups, with cat /dev/zero given as the example. Non-US keyboard input may or may not have issues.

Those four items line up with the design constraints. A software rendered terminal on a 68000 with no acceleration is slow, and a session that redraws on every keystroke inherits that. The encryption cost is a separate hit, since the cipher work happens on the same processor. And the channel breakage on large data is the price of a low bandwidth link with a small memory budget.

The keyboard caveat is worth understanding rather than dismissing. A client that renders the terminal with libvterm has to map key codes to characters, and a layout where the key codes and the characters differ is a genuine source of input bugs.

The list also contains one entry that is not a technical problem at all, which tells you the author has a sense of humour about the project: a link to a GitHub issue asking how to pronounce ssheven.

The to-do list is a specification of what a finished client would need

The features that might happen section reads as a design document for the 1.0 release, and grouping the items shows which are about correctness and which are about feel.

Correctness and capability come first. Improved unicode support, basic scp file transfer, a configurable terminal string, configurable or auto-choosing SSH buffer size which the README says improves the feel for faster machines, a known_hosts reset option, more complete colour support, and keyboard-interactive login. The known_hosts reset option and keyboard-interactive login are the two that change what the client can talk to, since a server that requires keyboard-interactive authentication cannot be logged into by a client that only does password or public key.

Presentation comes next. Nicer error presentation for more failure cases, reading the Apple HIG and cleaning up the UI and UX, all the license info in an about box type thing, and multiple terminal windows open at once. The mention of the Apple Human Interface Guidelines is a strong signal about the intended audience, since following the HIG is what a Mac developer would do.

Then there is the hardware and packaging work: finishing and uploading the papercraft box, the floppy sticker artwork and the icon and logo svg, and better debug output.

Reading this list as a whole, the project is not trying to be a full terminal emulator. It is trying to be a good SSH client on a platform that has none, with a scope that stops at one connection at a time and no scp beyond a basic version.

Where a terminal emulator with a modern client would serve you better

The honest alternative is not another SSH client for classic Mac OS, it is running a modern SSH client on a modern operating system and using the classic Mac only as a terminal. That approach sidesteps every known problem in the list, because the encryption and the rendering happen on hardware that can do both quickly, and the Mac is left doing what it is good at, showing text.

The difference in approach is worth being precise about. ssheven is a native client that speaks Open Transport, implements the protocol on the machine, and renders a terminal in software. The alternative is a modern client running elsewhere that speaks to the Mac over a serial line, a local network or a terminal emulator with a network link, which means the Mac displays characters and forwards keystrokes while the cryptography happens somewhere else.

That alternative is much less useful when the machine is a period-correct exhibit with no network hardware of its own, or when the point is to run the client natively on hardware you are restoring. In that case ssheven is the only option, and the performance complaints become a condition to live with rather than a reason to avoid.

There is a second consideration in the licence, which is unusually clean. The project is licensed under the BSD 2 clause licence, with the file in the repository, and the README states it plainly. A two clause BSD grant is permissive, requiring only that its copyright and licence notice be kept, which is a licensing note rather than legal advice and matters more here than usual because the hardware is old enough that hobbyists and museums will fork it.

The maintenance record is current, with the last push on 2026-08-26 and the repository not archived. The releases tell their own story, though, with 0.8.8 on 2021-07-25, 0.8.9 on 2021-12-30 and 0.9.0 on 2025-02-16, so the gap between the last two releases is more than three years while the code itself has moved recently. The version number has stayed below 1.0 throughout, which matches the README's own statement that pre-1.0 versions should be considered alpha or beta quality.

Editorial conclusion

Adopt ssheven if you are restoring a classic Mac OS machine and need real SSH rather than a terminal emulator running a modern client, since that is the gap it fills and the reason it exists. Do not adopt it as a general purpose SSH client, because the known problems include slow screen drawing, high input latency, and a channel that can break on a large amount of data, and because everything before 1.0.0 is alpha or beta quality. Verify first that your machine meets the hardware floor of a 68030 with 2MB of RAM and System 7.1 or later, that you have the Thread Manager extension if you are on a version below 7.5, and that Open Transport networking is present, since the client depends on it.

Frequently asked questions

Official sources

1. cy384/ssheven on GitHub
2. Issues
3. License: BSD-2-Clause
4. README
5. Releases