Our great sponsors
-
ssh3
SSH3: faster and rich secure shell using HTTP/3, checkout our article here: https://arxiv.org/abs/2312.08396 and our Internet-Draft: https://datatracker.ietf.org/doc/draft-michel-ssh3/
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
wstunnel
Tunnel all your traffic over Websocket or HTTP2 - Bypass firewalls/DPI - Static binary available
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
There is now an open issue: https://github.com/francoismichel/ssh3/issues/79
SSH over QUIC exists: https://github.com/moul/quicssh.
I don't see any advantage of layering HTTP/3 here. It adds more friction, and the only advantage it brings is being able to "hide" the SSH server over a URL path. I guess x.509 certificates would be fine, but SSH hostkeys, SSHFP or TOFU is enough and far more secure (because it implicitly pins the server public key).
It's a relatively new project from the looks of it, so I'd definitely not use it anywhere half important having to create something interesting with QUIC and HTTP/3.
If you want to tunnel UDP (WireGuard) or TCP (SSH) over WebSocket protocol, check out https://github.com/erebe/wstunnel
Also https://github.com/nnathan/monopiped. Just plugging my own project.
If hosts are configured with SSH certificates as part or their setup, you can definitely skip TOFU and determine trust on the first connection. That won't work for the "I need to connect to a random IP address" scenario, but any cloud server exposing SSH can be configured with a certificate signed by a company/personal SSH certificate authority.
You could configure something delightfully atrocious like https://github.com/mjg59/ssh_pki but I think for most use cases where you connect to loads of SSH servers, host keys and certificate authorities will work just fine.
That already has a (brutal) solution now - sslh https://www.rutschle.net/tech/sslh/README.html - the current version is more sophisticated, but it was originally just a perl script that would send the connection to sshd or the https web server, based on regex matching on an initial string (and I probably timing out and going to sshd if it didn't see one? Something like that, I haven't dug out the old code to check.)
SNI is absolutely needed. Over at https://pico.sh we have to request an IP for each ssh server even though from a resource perspective we really only need 1 VM. It increases the complexity of our deployments and overall makes us want to figure out how to merge all of our SSH apps into one.
For oidic there's at least:
https://github.com/salesforce/pam_oidc
https://github.com/EOSC-synergy/ssh-oidc
For oidic there's at least:
https://github.com/salesforce/pam_oidc
https://github.com/EOSC-synergy/ssh-oidc