CLI and browser client available.
That’s what I do currently with some of my hosts.
SSH can sometimes authenticate intent, like Yubikey touch.
Using wireguard for authentication is a mistake. The category of mistake is usually referred to as ambient authority, often exploited via a confused deputy.
In one sense, this is no different than adding a public key to ~/ssh/authorized_keys.
If you control the key, you control the authentication.
What makes SSH different is the encrypting part. The keys were only introduced to be used by the encryption algorithms. Users and multiple identities were a core detail of nixes much before SSH
It’s clunky to distribute and rotate ssh keys, but much easier to do that with WireGuard credentials.
The shell implementation is already under the MPL-2.0 and worth a look at for anyone who's interested https://github.com/noisysockets/shell
A 4-year-old version of security-critical software. You understand why this is less than compelling?
Maybe, but we don't know until we hire a lawyer to check it out. And we don't.
On the other hand, I don't think you can afford a lawyer to defend your bespoke license either.
In either case, the license is meaningless.
A great use case in the enterprise is wrapping old but mission critical systems that don't support modern encryption or authn requirements with WireGuard. SSH is a demo for that use case- there's a lot of proprietary TCP data protocols out there in the legacy enterprise world!
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).
That custom license may stop people from using the remote shell. Luckily the library is just MPL 2.0
[1] https://noiseprotocol.org/noise.html#introduction [2] https://github.com/noisysockets/noisysockets
The fundamental thesis behind noisy sockets is, "What if your network endpoints were processes instead of machines?"
And as you say bypassing the host networking stack actually brings a lot of benefits (eg. avoiding those VPN leak shenanigans), it's actually interesting when you squint enough it begins to even look vaguely something like QUIC (in that you have multiple encapsulated streams/channels/sockets going over UDP with their own congestion control).
Peer discovery and NAT traversal are next on my list. I'm going to implement a kind of userspace lighthouse peer that will advertise peer endpoints to the network. I'm still trying to think about how I will deal with TURN/DERP. I suspect I'll tunnel WireGuard over WebSockets and just have each peer listen on UDP/TCP. Maybe one day that will allow even an in browser peer with WASM (which I'm sure someone will find an interesting use case for).
Also on the list is fine grained authentication/authorization (interestingly netstack has an iptables implementation), some of it will be opensource and some of it will be source available (sorry for the SSO tax).
I would also suggest looking at ZeroMQ if you haven't yet; their design & implementation is really fantastic. They implement the bare bones in the library, and then you can go implement your own components with it for whatever architectural topology you want. So for example, you could make a closed-source paid product of a connection broker using the library, and somebody else could make one for free as open-source. Both have their use-cases, and they're both compatible with all the other apps in the ecosystem. This benefits you as it legitimizes the product and grows the ecosystem, and encourages more use due to its flexibility
Some kind of paid connection broker / app platform actually sounds like a solid way to build a sustainable business out of something like this.
I'm trying to avoid the tailscale model of having to lock up the control plane.
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
The flow I've seen is "Wireguard server has its listening port open. Clients (with all ports closed) connect to the server on its open port."
After that, all connections can still happen. Server -> client, client -> server.
> NAT Traversal: The NAT entry created by the client's outgoing connection allows the server to send packets back to the client.
> VPN Tunnel: The established VPN tunnel enables bidirectional communication, allowing the server to reach the client without the client needing an open port.
But you don't have to trust me, the AGPLv3 starts immediately.
I'll update the source headers in the following days.
Thanks!
The custom license is a pretty basic derivative of the FSL-1.1 with MPL-2.0 instead of Apache (for a weak copyleft), I think I might keep the custom license in place (I'll make the very minimal changes from the stock FSL-1.1 clear).
But adding an AGPLv3 license for those with ambiguity concerns is totally okay with me (it's ultimately more restrictive than the source available license in a lot of ways).
Thank you for the great suggestion.
It seems like it could do some of the same usecases.
One thing it does have in common with mosh, is excellent roaming support. And the other major selling point is that the remote shell protocol is browser compatible. No need for things like "Shell In A Box".
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`.
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.
You can use timing of packages send to e.g. extract passwords.
(hence why SSH clients normally take additional precautions)