Table of Contents
- What is this?
- Why write this when ssh already exists?
- Has xs been audited for security?
- But forks of openssh exist with PQ (Post-Quantum) KEx/KEM support.
- Openssh has this cool 'keystroke timing obfuscation' thing, does xs?
- You should have written it in Rust!
- Why won't the server xsd build in Windows?
- Why is there a separate xspasswd util and config file?
This page captures commonly-asked questions and their answers. Anticipated questions which haven't actually been asked should also be addressed here, within reason; consider adding to the core documentation instead, if it isn't a simple question or answer.
What is this?
This is a remote access client and server solution with encrypted communication, allowing standard UNIX-style shells and secure file copies. If ssh didn't exist, or were created in a parallel universe, this is what admins might use instead.
Why write this when ssh already exists?
Because sometimes the best way to learn about something is to recreate it. An artist doesn't become proficient by just looking at others' works, they need to do some creation themselves :)
And, to be honest, I found the existing openssh codebase to be pretty heavy, burdened by a lot of history. After many evenings of dead ends trying to properly add support for new algorithms (I could get the negotiation tables working, but could not figure out how the heck one communicates the session keys to each newly-opened channel... fork() hell), I realized that Go (golang), with its extremely clean concurrency model and strong standard library might allow a much cleaner implementation of what I wanted.
Yes, yes, I know openssh is what it is because it has been battle-hardened over around two decades, and a lot of the complexity there is there for a reason. However, a lot of it is also there because C is much lower-level, especially in its string- and buffer-handling -- a minefield of security 'oopsies'. (but I still love you, C!)
Has xs been audited for security?
Nope. Have at it, please. Feedback is welcomed, and the more secure it can be made, the better.
That said, I think it can be objectively said that using Go greatly diminishes the attack surfaces for buffer overflows, code injection and so on due to Go's native string/slice facilities, and the fact that Go by default panics and dies early on any violation of uninitialized pointers and bounds exceptions, rather than merrily stomping memory. The client and server code itself contains no unsafe blocks which turn off such protections, and any underlying crypto algorithms which aren't written in pure Go are from the standard Go crypto libraries which have themselves been externally audited for security. The same can be said for login, logout, logging and terminal handling libraries, which are also from the Go standard library, which sit atop the Linux/BSD/Windows OS APIs, so those are also heavily scrutinized.
However, as mentioned in the README.md, all of the KEx/KEM algorithms are experimental, so one should keep up to date on the security of those. That's the main purpose of this project, to use those algorithms to prove their practicality and to offer alternates to those used in the main openssh ecosystem.
2023-10-xx: for example, djb (Daniel J. Bernstein) has recently asserted that the NIST analysis of the KYBER PQC KEM makes an error (intentional or not, hello there NSA!) that overestimates the strength of KYBER-512, so KYBER-768 and above are probably recommended as mimima when choosing that algo ...
But forks of openssh exist with PQ (Post-Quantum) KEx/KEM support.
Openssh only added PQ algos after I had this project up and running, almost 3 years afterwards. Again, I see Go as being more inherently secure, and the source code easier to maintain, which also aids in security when making future changes.
A diversity in solutions for network shell access is good.. we've all relied exclusively on openssh for a long time, and a monoculture is dangerous. (Recall the 'heartbleed' fiasco and the scramble to fix and/or find other SSL/TLS libraries to avoid a security monoculture).
Openssh has this cool 'keystroke timing obfuscation' thing, does xs?
Yeah, I did that early on with this project, almost five years before openssh announced it (Oct 2023 for openssh vs. May 6 2018 for xs, commit a1f4e034). It could certainly be improved, but I can say with some confidence that xs did interactive keystroke timing obfuscation (and file copy and tunnel traffic too!) before it was cool <sips a soy-latte> :P See the discussion on 'chaffing' in general elsewhere in these docs.
You should have written it in Rust!
Go away. Just kidding. Well, half-kidding. I plan to learn Rust someday, but not today. Feel free to port xs to Rust if you're a wiz, and I'd be interested to compare the implementations, really! I'll still prefer the solution which is easier to read and with lower SLOCC, which I honestly doubt Rust will achieve... I may be proven wrong, and I'll happily buy a round of beer at the release party where this is demonstrated.
Why won't the server xsd build in Windows?
Windows has a completely different console and file handle model from UNIX/POSIX OSes. I jumped through some hoops to get the client xs building and running under MSYS2, but the server side needs a lot more platform-dependent voodoo. I don't have the expertise nor desire to go off into the weeds on this; contributors are welcome. If you can make xs a first-class terminal app for Windows, please send patches!
Even better, if you can, contribute such cross-platform console and exec/file-handle code to the Go core standard libraries. They are still grappling, AFAIK, with how best to support an OS-neutral terminal/console model.
Why is there a separate xspasswd util and config file?
Out of caution in early development. One may still use it, but xsd now uses the main system passwd/shadow infrastructure by default (one may try the deprecated 'xspasswd' facility by passing -s 0 when launching xsd).