Time to announce Noisy Sockets Shell, the first in a series of WireGuard powered applications I'm working on. Noisy Sockets Shell is an SSH replacement that uses WireGuard for authentication and encryption, and WebSockets for communication.<p>CLI and browser client available.
Thanks everyone for the wonderful Sunday afternoon surprise, I'd posted this originally on a Friday and I guess a lot of us were out watching the polar lights. This was a fun project to work on.<p>Right now it doesn't support a multi-user daemon mode, kind of similar to mosh. But in the future because the server is able to cryptographically verify the source of connections, it's only a matter of time until I implement something akin to a per user `~/ssh/authorized_keys`.<p>With noisysockets I'm effectively building out a suite of WireGuard powered "apps". Which are small, unprivileged, programs you can attach to a WireGuard network and will act as virtual peers.
Why does the client have a listen port?<p><pre><code> nsh config init -c server.yaml -n server --listen-port=51820 --ip=172.21.248.1
nsh config init -c client.yaml -n client --listen-port=51821 --ip=172.21.248.2
</code></pre>
Typically, servers have easiest to configure NAT/firewall/port forwarding and clients (to me) are basically thought of as "not going to get through their router/firewall configuration no matter what".
Would you consider dual-licensing this under a FOSS license like the AGPLv3? That's strong enough copyleft that I think you'll be safe from what you're trying to avoid with your current nonstandard license.
Pretty cool, but the license is pretty toxic to commercial adoption. I would suggest also licensing under MIT, BSD or Apache if you want this to ever achieve any widespread usage. Unfortunately you are competing against SSH which has a mature ecosystem so if you want widespread usage then you need to make it attractive legally as well as technologically.
One surprising tricky part of encrypting "live input" protocols (like typing send over a shell) is that just encrypting them is not enough.<p>You can use timing of packages send to e.g. extract passwords.<p>(hence why SSH clients normally take additional precautions)
Why fork/copy&paste wireguard-go source code instead of using wireguard-go's existing netstack package? Couldn't you help improve instead?
To what extent does this replace mosh? <a href="https://mosh.org/" rel="nofollow">https://mosh.org/</a><p>It seems like it could do some of the same usecases.
If I can make a rough attempt at summarizing this: this is basically a PoC of a remote shell using the Noise Protocol Framework[1] with implementation Noisy Sockets[2] to effectively use UDP to tunnel a connection from one application to another directly and securely. If you squint at it, Noisy Sockets is basically like TCP+TLS, but UDP+SomeOtherCrypto. The library is a drop-in replacement for the Go 'net' library. All the protocols (including tcp/udp) are implemented in userspace.<p>This has some really interesting use cases (like not having to use HTTPS to get a bidirectional secure communication channel... not being limited by firewalls... not requiring an OS to upgrade its tcp/ip stack...). Normally I'm a pessimist but I kinda like this thing (the library, not the remote shell). Just needs a less clunky way to discover and route to services, a simpler way to configure a connection to the remote host, and extensible authentication/authorization (public keys pose management problems and don't fit some use cases).<p>That custom license may stop people from using the remote shell. Luckily the library is just MPL 2.0<p>[1] <a href="https://noiseprotocol.org/noise.html#introduction" rel="nofollow">https://noiseprotocol.org/noise.html#introduction</a> [2] <a href="https://github.com/noisysockets/noisysockets">https://github.com/noisysockets/noisysockets</a>