3 ms·
Is this wayland all over again? We do three or four new things well, and everybody is supposed to just stop doing everything else ? Is this "a secure shell" (a
by znpy 3y ago
Is this wayland all over again? We do three or four new things well, and everybody is supposed to just stop doing everything else ?
Is this "a secure shell" (as in, somebody's personal spin on the topic) or like a new "official" direction?
The readme isn't clear on these aspects.
- mseepgood 3y agoIt's obviously a personal project.
- uxp8u61q 3y agoIt's just someone's project. As far as I can tell it's unrelated to IETF, if that's what you mean by "official". In any case it's presumptuous for the author to call this "SSH3".
- brunoqc 3y agoit's probably just ssh + http/3
- amluto 3y agoWhat does “official” mean? The OpenSSH team? IETF? Anyway, SSH authentication is extremely inflexible, and the protocol is not particularly performant, especially on large bandwidth-delay links. Moving to HTTP3 seems like an excellent idea if it’s implemented well. (Although… we really need a way to do TLS/QUIC to an endpoint without a domain name.)
- uxp8u61q 3y agoThe RFCs for SSH2 were all published by IETF, so I would definitely expect IETF to be involved in a project that claims to be "SSH3". If some random person started an OS project and called it "Windows 12", people would rightfully be confused.
- lnxg33k1 3y agoAgree I also think that we should leave naming stuff SSH to IETF and OpenSSH to OpenBSD, in this case the maintainer seems to be unrelated to both
- tlivolsi 3y agoAgreed. The name is terribly misleading.
- ctz 3y agoThe IETF SSH working group was disbanded in 2006. You will be waiting a long time if you expect anything else to come from there by magic.
- aseipp 3y agoYeah, right now for auth, if you want to use e.g. OIDC I think the best you can do is to essentially shove everything in the square hole using very short-lived SSH certificates and OOB auth flow; e.g. "open this browser link to get a cert for the next 15 minutes/24 hours." So, you're basically treating short-lived certs like session tokens, more or less. I got this working with my own homegrown SSH CA infrastructure last year, but never took it out of prototype stage. Even slightly more flexible authentication would be very welcome.
- amluto 3y agoCloudflare offers this as a service. It’s obviously a second class citizen (it’s intensely buggy, has low availability, doesn’t work especially well even on a good day, has incoherent configuration, and no support whatsoever). On the other hand, all Cloudflare configuration seems incoherent, and it gets more so over time. I was recently highly entertained when I tried to access one of the Zero Trust [0] pages. The UI cheerfully informed me that only the new UI could configure Zero Trust, and it redirected me to a new domain that was IIRC “one.dash.cloudflare.com”. You can’t make this up — maybe it’s called One Trust internally? The new panel looked quite a lot like the old one except that the Zero Trust pages worked. Well, “worked”. None of the Zero Trust config makes any sense. [0] Is there any logic at all to what lives under the Zero Trust umbrella?
- the8472 3y ago> (Although… we really need a way to do TLS/QUIC to an endpoint without a domain name.) Generate self-signed cert, let the client TOFU. And skip the HTTP part. Just like SSH. There's no reason to do things like a browser.
- amluto 3y agoI think we could do much better than this with a small amount of creativity. But it really ought to be possible to securely configure locally-connected devices with a browser, and this is not really possible today.