Dirkjan Ochtman: writing

Why?

Many large organizations have shown that up to 70% of security vulnerabilities in software written in C and C++ happen due to memory safety issues (Microsoft, Google). In the US, government agencies have been advocating for the use of memory-safe programming languages for a few years now. The Prossimo project lists three risk criteria to help prioritize where memory safety is most important:

1. Very widely used (nearly every server and/or client)
2. On a security boundary
3. Performing a critical function

SSH servers meet all three of these criteria.

OpenSSH is the predominant implementation; it's written in C and has been around for decades. It continues to suffer from memory safety issues to this day. I started OxiSH because I think it's worth investing in a memory-safe alternative.

What's been done?

Before starting on OxiSH, I spent some time looking for existing SSH implementations in Rust that could help me bring this idea to life sooner. In particular, I looked at russh which seems to be fairly popular. However, I noticed that it implements some old crypto primitives and seems to have a fairly monolithic design, so I decided to start from scratch instead.

Although I could keep working on OxiSH in (semi-) stealth mode, I think it's now in a good enough state to announce publicly. That does not mean it is ready for production usage, and there are a bunch of limitations (see below). This is a starting point, looking for feedback and contributions from other folks; I will soon start dogfooding this on my own server as well.

I have a Tokio-based async networking server with a sans-I/O SSH protocol core, public key authentication support (with Ed25519 and ECDSA P-256 keys only), and a basic shell implementation that can spawn a child process and connect it to the SSH session. It gets tested on Linux and macOS against OpenSSH clients in CI. Windows support would be nice but will require someone else to step in. There is no client implementation yet, and I currently don't have plans to work on that, but the sans-I/O core could well be used to enable it. Beyond the low-level sans-I/O API, there's also a (currently small) library API to enable reuse.

Cryptographic primitives are implemented with two different backends, graviola and aws-lc-rs. Cargo features can be used to select which backend is used at compile time; graviola, the default, is easier to build but only works on x86-64 and ARM64, while aws-lc-rs is more portable, should be slightly more efficient, and can be compiled in FIPS mode on Linux. It implements hybrid post-quantum key exchange using the mlkem768x25519-sha256 algorithm, and curve25519-sha256 is supported for key exchange as a fallback algorithm for older clients. Ed25519 and ecdsa-sha2-nistp256 are the only supported public key algorithms, AES-128-GCM is the only supported encryption algorithm and SHA-256 is the only supported hash algorithm. It should be fairly easy to add other algorithms that are supported by the underlying backends, but I'd like to keep the set as small as possible to reduce attack surface.

I have made an effort to review historic OpenSSH vulnerabilities to make sure both the design and implementation of OxiSH avoid similar mistakes outside the memory-safety realm. I would like to pay for an external audit of the codebase in the future, but I'm unlikely to be able to fund that work myself.

Here are some of the more obvious missing features:

• No agent forwarding, let alone other kinds of forwarding
• No scp or sftp support
• No password authentication

Full feature (or even bug for bug compatibility) with OpenSSH is explicitly not a goal of this project, but I'd like to hear more about what people would need to see to replace OpenSSH in their environment. Please file an issue!

Who have been involved?

I wrote most of the code, and I have reviewed all of it in great detail. I have more than 10 years of experience writing Rust code, and have been maintaining some popular network protocol projects for the last few years, including:

• rustls, a widely used TLS library in Rust
• Quinn, a popular implementation of the QUIC protocol in Rust
• Hickory DNS, a DNS implementation in Rust

For a few weeks earlier this year, I was fortunate to get help from the fine folks at the Trifecta Tech Foundation, who were able to get an investment from the Sovereign Tech Agency to help figure out some of the core platform interactions in the server, including an initial draft of privilege separation and terminal handling. We hope to continue our collaboratation on this project in the future.

Where to from here?

As mentioned above, this is just a starting point. Please leave feedback and/or contribute PRs directly (but please check out the contributing guidelines including AI policy before jumping in). If you want to support my work on OxiSH and other projects, please consider sponsoring me. If you want to get in touch privately, my email address should be easy to find from my website.