61–70 of 206 posts
People are being perhaps a little too over dramatic here. Yes, this is not SSHv3 as defined by a standards body. It is very much SSHv2 over HTTP/3. (Which sorta sounds like how HTTP/3 is actually HTTP/2 over QUIC) But there is lots of SSH servers and clients, such as Dropbear SSH, OpenSSH, libssh, libssh2 (which is very different from libssh which also supports sshv2), and more. So I don't blame the creators from put…
SSH over QUIC would be nice. 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 no…
SSH3 seems a bit of a clickbait project name, it's not clear to me that this project uses anything protocol-wise from SSH though it offers similar functionality. A PhD project from Belgium that combines several Golang libraries to offer HTTP-based authentication on top of backwards compatibility with OpenSSH keys, configuration, agents, etc. -- it looks pretty solid but the associated paper titled "Towards SSH3" ackn…
If you want SSH via UDP, try mosh. If you have it installed on both client and server side, it just works, re-using auth, sessions etc fron ssh itself and only replacing sending actual session bytes back and forth. Don't break on unstable connections, have way lower latency
Presumably you'd choose a different port but then it'd be pretty obvious you're running something if your server has a random HTTPS server exposed on port 444 or whatever.
WARNING: This is not ssh3. This is someone’s project. Install at your own risk.
I'm going to use this to do UUCP over QUIC.
Aside from the weird claim of being SSH3, this project seems to not understand that ssh already supported cert auth.
What if you already run a web server which uses port 443? Strange that the readme doesn't mention that scenario because it's extremely common. Presumably you'd choose a different port but then it'd be pretty obvious you're running something if your server has a random HTTPS server exposed on port 444 or whatever.
Earlier quoted context omitted.
How intentionally vague.
I assume he means with the encrypted metadata in HTTP/3 / QUIC that it makes it harder as a security admin to "peek" at what is going on in the network. In my opinion its short sighted, because if we care about security, then we should care about user security and privacy as well. Because if the security admin has the ability to packet inspect stuff, so does a potential malicious app.