13 ms·

SSH3: SSHv2 using HTTP/3 and QUIC

• cwillu 3y ago
  Not related to IETF, no RFC, entirely unrelated to the processes involved in the standard. Protecting against the potential for confusion from and/or abuses like this is what trademarks are for.
• 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 ago
    It's obviously a personal project.
  • uxp8u61q 3y ago
    It'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 ago
      it's probably just ssh + http/3
  • amluto 3y ago
    What 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 ago
      The 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 ago
        Agree 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 ago
        Agreed. The name is terribly misleading.
      • ctz 3y ago
        The 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 ago
      Yeah, 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 ago
        Cloudflare 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?
• alphazard 3y ago
  This is pretty neat, definitely better to move to UDP, so that we can have the proper response to unauthorized contact--no response. QUIC is fine as is though, no need to layer HTTP3 on top of it.
  • heyoni 3y ago
    Isn’t it necessary for oauth?
    • vlovich123 3y ago
      It might be easier to integrate but you’ve got a custom server and client in this case so it should be possible to do both without HTTP being involved for the server/client layer without an HTTP server? At least I think that’s right but it’s been a long long while since I wrote OAUTH code. Seems like it’s primarily to implement the masking feature to pretend to be a normal HTTP server hosted on a port until the shared secret URL is knocked.
    • the8472 3y ago
      The client and server need to talk http to the authorization server, that doesn't mean they need to talk http to each other.
  • vlovich123 3y ago
    The reason they’re using HTTP is to allow for hiding the SSH server so that it pretends to be a dummy HTTP server that responds to 404 on all requests unless you know the special random URL that hosts the SSH capabilities. It’s a neat idea but overkill when you’re not using that capability (didn’t dig into the code so maybe it is bypassed if you don’t ask for a secret URL). It does make me hesitant as I don’t know how secure Go’s HTTP stack is since an exploit there could expose quite a bit and I don’t know that it’s been hardened to host directly, but it is an interesting idea. May be worth hand-rolling a custom server to do the routing but at the same time it makes it easier to fingerprint. I think it makes more sense to separate the routing secret to a standard reverse proxy that’s harder to fingerprint. One could imagine that the secret URL idea in a normal HTTP stack is susceptible to scanning techniques since there’s only one route to guess.
• egberts1 3y ago
  Not going there with anything HTTP/3. Disclaimer: I write network packet parsers for XNS/IPS/IDS for a living, to look for "bad things".
  • qwertox 3y ago
    I wish you would share some of your thoughts.
  • mmaunder 3y ago
    How intentionally vague.
    • lajamerr 3y ago
      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.
      • insanitybit 3y ago
        Odd, surely SSHv2 already suffers from inability to inspect on the wire.
        • egberts1 3y ago
          From the Github: SSH3 is a complete revisit of the SSH protocol, mapping its semantics on top of the HTTP mechanisms. In a nutshell, SSH3 uses QUIC+TLS1.3 for secure channel establishment and the HTTP Authorization mechanisms for user authentication. So, it has nothing to do with SSH2; more about HTTP/3-QUIC security theater: hostname is still being sent over TLS/1.3 negotiation.
          • insanitybit 3y ago
• k__ 3y ago
  How does it compare to Mosh?
  • mcfedr 3y ago
    Sounds like it as to solve completely different set of problems
• out_of_protocol 3y ago
  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
  • georgyo 3y ago
    Mosh and this project have fairly different goals. Mosh uses regular TCP SSHv2 to authenticate and setup the udp connection. As such your initial connection time is actually slower than just normal v2, and you cannot auth with something like oauth. Mosh is heavily focused on interactive sessions. You could not use mosh for batch programs easily.
    • gabeio 3y ago
      > Mosh is heavily focused on interactive sessions. You could not use mosh for batch programs easily. Correct, the goals are better human interaction with a high delay internet or server. Effectively allowing the client side to guess a bit as to where your input went (it does decently at it). But the key thing that I've loved is even if my client machine goes to sleep and I go to a different building I'm still connected to the server. That is wonderful. Agreed the connection time is slower. Mosh = Mobile shell.
  • v3ss0n 3y ago
    eternal is better than mosh https://eternalterminal.dev/ https://eternalterminal.dev/
    • binkHN 3y ago
      Neat. > While mosh provides the same core functionality as ET, it does not support native scrolling nor tmux control mode (tmux -CC).
    • ckwalsh 3y ago
      Do you happen to know where I can read about how ET and Mosh each establish their connections? I have used Mosh for years and recently heard of ET, but when I tried it I experienced noticeable hangs that I don’t get with Mosh, and I went back. I heard from several people that “ET is the new Mosh”, but it won’t be for me unless I can figure out/resolve those hangs
• mmaunder 3y ago
  WARNING: This is not ssh3. This is someone’s project. Install at your own risk.
  • heyoni 3y ago
    They should have called it SSHTTP3
    • tsimionescu 3y ago
      Secure SHell -Text Transfer Protocol 3?
    • deleted 3y ago
      [deleted]
  • arp242 3y ago
    Anyone should treat any new crypto project which hasn't seen a lot of testing from others as such, no matter who it came from. Even if this was some sort of proposal of the OpenSSH people. The project is associated with the Louvain university; I would rate the risk of outright malicious tomfoolery to be quite low.
    • tjoff 3y ago
      Well, if it was a proposal of the OpenSSH people you'd bet it would get a lot of testing from others real quick. But to even consider calling it SSH3 is really quite silly, first impression doesn't exactly inspire confidence.
      • arp242 3y ago
        "Confidence" in what? Ability to name things? It's making a mountain out of a molehill. It's certainly not an issue with the crypto or code.
        • tjoff 3y ago
          Judgement? Having attention for detail? Being in touch with the community? Just a bad look / first impression.
• password4321 3y ago
  If you want to tunnel UDP (WireGuard) or TCP (SSH) over the WebSocket protocol, check out https://github.com/erebe/wstunnel https://github.com/erebe/wstunnel
  • kernel_cat 3y ago
    Also https://github.com/nnathan/monopiped https://github.com/nnathan/monopiped. Just plugging my own project.
  • PrimeMcFly 3y ago
    Why would you tunnel WireGuard over SSH?
    • tssva 3y ago
      Perhaps reread the comment. It presents info for running Wireguard or SSH over websockets and not running Wireguard over ssh.
    • password4321 3y ago
      Although not relevant to my post above, tunneling WireGuard over SSH sounds like an interesting challenge... Because WireGuard and SSH are at different layers of the network stack, it might be necessary (though slow) to bridge two WireGuard networks through a single TCP socket port-forwarded by SSH. I'm actually curious now what tools would best be used to accomplish this, how much effort would be needed to configure things, and how badly performance would suffer when faced with normal internet traffic congestion.
      • oarsinsync 3y ago
        > I'm actually curious now what tools would best be used to accomplish this “Tunnel UDP over SSH” https://superuser.com/questions/53103/udp-traffic-through-ssh-tunnel https://superuser.com/questions/53103/udp-traffic-through-ss... has some suggestions
  • IAmLiterallyAB 3y ago
• Jhsto 3y ago
  Sounds like something to try in an internal network where you want to do X11 or Wayland application forwarding!
• zaik 3y ago
  This is not related to OpenSSH or the RFCs for SSH3 published by IETF. It is just someone's random project.
  • say_it_as_it_is 3y ago
    2 phd students
  • stjohnswarts 3y ago
    It still seems like a nice experiment if nothing else. If only it was done in rust ;)
    • say_it_as_it_is 3y ago
      Not if they wanted to complete the work in time
  • nextaccountic 3y ago
    I think it was a lot of hubris to call this ssh3, as if it were to be picked officially
    • pdntspa 3y ago
      Yeah, it is really rude of them
• georgyo 3y ago
  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 putting SSH in the name. The code itself looks like mostly glue code to other more well established libraries. I'm not saying that they didn't introduce new flaws, just that they did not roll their own crypto here. Their paper on their work is pretty interesting: https://arxiv.org/pdf/2312.08396.pdf https://arxiv.org/pdf/2312.08396.pdf I kinda hope this succeeds. The faster connection time is nice, but really OpenSSH is so change adverse that it's painful. IE, I have to have a pretty large patch sets to open SSH, one of them being HPN ssh for getting any kind of reasonable throughput over high latency links. This patch set is decades old and the problems well known, but OpenSSH maintainers do not care. Replacing the transport layer would force things like having reasonable window scaling. Another is loadbalancing and routing SSH connections. You cannot know where a client wants to connect to till after they done a full hand shake. This is pretty painful. If we had something like SNI we could route clients to the correct servers using only a single IP and port. I fully welcome these ideas and am glad a group is working on testing these concepts. Please don't dismiss things too hard too soon.
  • dang 3y ago
    Ok, I've put SSHv2 in the title to make that clearer. If there's a better way, we can change it again.
    • nixgeek 3y ago
      I don’t think this is SSHv2 though the GitHub talks about reimplementation on HTTP semantics, and the paper illustrates SSHv2 vs SSH3 as being extremely different for session setup. In naming; Francois also explains SSH3 is a concatenation of SSH and HTTP/3 — we can not like that here on HN (due seemingly to the lack of IETF involvement?) but it’s what the project creators picked.
      • 3y ago
• adontz 3y ago
  I believe security models for HTTP and SSH are pretty different. HTTP is usually public and anonymous, SSH is usually private and authenticated. While QUIC is definitely a great technology for HTTP use case, I'm not so sure about SSH. Not saying it's not, just it's something to reason about. For example x509 seems to be a disadvantage to me. I do not want anyone with a cheap DigiCert certificate be able to log in to my server, even as a result of some fat finger misconfiguration. OAuth assumes that both client and service provider can reach identity provider. Is it so for most serves? I am used to see pretty restricted setups, where many servers have no internet access and only update from a private package repository. From one side, I really like the idea of reusing HTTP. Who does new protocols these days? Everything is JSON or XML over HTTP. And it's good enough for most cases. But is it good enough for SSH? WinRM works over HTTP, but it uses Kerberos for authentication. Are there any significant real practical advantages? I don't see any. Are there any vulnerabilities, possibilities for misconfiguration, architectural flaws? Quite possible.
  • nixgeek 3y ago
    “cheap DigiCert certificate” is already possible with misconfiguration of SSH’s TrustedUserCAKeys and without any out of tree patches. https://smallstep.com/blog/use-ssh-certificates/ https://smallstep.com/blog/use-ssh-certificates/
    • frutiger 3y ago
      SSH Certs are not related to x509 PKI certs. SSH certs are created with ssh-keygen and is the result of one key signing another. The public portion of the signing key (ie. the “cert”) needs to be distributed separately.
      • vetinari 3y ago
        Did you follow the link? The point was exactly setting up X.509 PKI for SSH authentication. Yes, it can be used with SSH, that was the GP's point.
        • 3y ago
• ikiris 3y ago
  Aside from the weird claim of being SSH3, this project seems to not understand that ssh already supported cert auth.
  • deleted 3y ago
    [deleted]
• hackernudes 3y ago
  Maybe similar to https://github.com/moul/quicssh https://github.com/moul/quicssh I've done ssh over websocket before (to bypass a corp proxy)... been thinking about it a lot lately. I would love if mosh got support for different transports than just udp and it would be cool if the initial handshake could be done over http instead of ssh.
• password4321 3y ago
  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" acknowledges "This article is a first step" in the conclusion.
  • deleted 3y ago
    [deleted]
• Ayesh 3y ago
  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 not use it anywhere half important having to create something interesting with QUIC and HTTP/3.
  • mkesper 3y ago
    Ssh hostkeys offer no solution for first connect to ephemeral hosts.
    • jeroenhd 3y ago
      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 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. We can do with an ACME-like protocol for distributing these certificates, though.
      • mcfedr 3y ago
        Given how rare this is, using https seems like a great idea
    • Ayesh 3y ago
      Strict SSHFP can theoretically solve it [1], assuming it's used in the first place and has DNSSEC. I personally use it for all servers I manage purely because I like the additional security, but it not at all common and DNSSEC isn't all that perfect either. [1] https://aye.sh/blog/sshfp-verification https://aye.sh/blog/sshfp-verification
• jsiepkes 3y ago
  Missed chance not to call it SSHTTP3 ;-)
• tenebrisalietum 3y ago
  I'm going to use this to do UUCP over QUIC.
  • deleted 3y ago
    [deleted]
• wackget 3y ago
  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.
  • xgbi 3y ago
    Can't you simply `proxy_pass` the traffic with any load balancer or reverse proxy (that you probably have anyways if you use TLS)?
  • okasaki 3y ago
    You can run different hosts on one web server, like company.com goes to localhost:5555 (your app or whatever) and ssh.company.com goes to localhost:8443 (let's say you're running ssh3 on that port)
    • qingcharles 3y ago
      * depending on your web server/reverse proxy configuration [for instance, I run Kestrel and it really isn't designed to target more than one site; I do it, but it's like bending that Lego brick to make it fit where it shouldn't go]
      • okasaki 3y ago
        Yes I suppose, although you can always put a web server that does support it (like nginx) in front of your web server that doesn't support it.
        • qingcharles 3y ago
          Yeah, this is what MS used to recommend, although they now say their own version YARP is better.
  • xyst 3y ago
    Front load service with nginx server or load balancer… nginx exposed on 443: if route is /web then route to web service on port 1234 if route is /ssh3-secret-string -> route to ssh3 server service on port 1265 if route doesn’t exist then 404 …
• epaulson 3y ago
  I know this isn't an actual v3 of the SSH protocol, but if there ever is a version 3 of SSH, it really needs some kind of (encrypted) SNI or at least a standardized metadata block that can be passed to any jumphost without having the know the specifics of the ProxyCommand on that middlebox.
  • idorosen 3y ago
    `ProxyJump` already exists, so you don’t need to know where netcat resides on the jumphost anymore. SNI-like metadata might have some adverse security implications, but a fancier ProxyJump with session routing would be nice.
  • tux2bsd 3y ago
    [dead]
  • qudat 3y ago
    SNI is absolutely needed. Over at https://pico.sh 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.
    • mkj 3y ago
      Maybe if there were a DNS record for a SSH port number it could work? Separate port per server, not terrible.
• jhatemyjob 3y ago
  So let me get this straight, from reading the README, the only tangible benefit is faster session establishment? With the downsides being, he's using a more complicated protocol, which apparently has slower throughput?? I guess this is a cool experiment but why would anyone use this over OpenSSH or libssh2?
• rubyfan 3y ago
  Something about calling this SSH3 feels like when Comcast named a thing 10G.
• r1ch 3y ago
  I feel like they're missing some benchmarks here, show off the benefit that QUIC brings! OpenSSH's fixed window size significantly bottlenecks throughput on long fat links. I'd love to see ssh+rsync running at 2+ gbps.
  • pulpfictional 3y ago
    There is also: https://www.psc.edu/hpn-ssh-home/ https://www.psc.edu/hpn-ssh-home/ > HPN-SSH is a series of modifications to OpenSSH, the predominant implementation of the ssh protocol. It was originally developed to address performance issues when using ssh on high speed long distance networks (also known as Long Fat Networks: LFNs). By taking advantage of automatically optimized receive buffers HPN-SSH could improve performance dramatically on these paths. Later advances include; disabling encryption after authentication to transport non-sensitive bulk data, modifying the AES-CTR cipher to use multiple CPU cores, more detailed connection logging, and peak throughput values in the scp progress bar. More information can be found on HPN-SSH page on the PSC website.
    • formerly_proven 3y ago
      SSH started out with a maximum window size of 128K, which was bumped to 2M in the mid-2000s. It'd be entirely reasonable to bump this to the 64M to 128M range; it's not a fixed buffer allocated for each channel, and the peers explicitly manage the window size, so there really shouldn't be any compatibility issues. This would already solve most of these issues, the more complicated parts of HPN-SSH aren't really needed, and things like multithreaded crypto are entirely unnecessary with modern CPUs unless you need to saturate a 100G link with one connection.
      • nubinetwork 3y ago
        > unless you need to saturate a 100G link with one connection Maybe not 100gig, but I routinely transfer data over 10gig links. I used to be a heavy user of HPN, but Gentoo pretty much stopped supporting it because the multithreading is supposedly broken.
• ironhaven 3y ago
  Why is there http/3 in the middle? SSH over QUIC makes a lot of sense and was something I thought about before. The SSH protocol is designed to multiplex many “channels” over an encrypted tcp socket. Over each channel you can run things like a shell or SFTP. It would need some engineering but you could keep the same SSH features but replace the multiplexing channels over tcp with QUIC channels over udp. Where does HTTP/3 fit in besides to add overhead?
  • egberts1 3y ago
    Do you want to maintain a state machine for each QUIC-SSH session 1-N pairing? Or worse, M-N pairing?
    • CoolGuySteve 3y ago
      Yes. The attack surface would be much smaller.
    • anticensor 3y ago
      Why not have 1:1 relationship between QUIC connection IDs and open SSH sessions?
      • egberts1 3y ago
        Profiling ... of SSH sessions at QUIC level, that's why we shouldn't do 1:1 mapping between QUIC session and SSH session.
  • wmf 3y ago
    You can use HTTP for authentication.
    • ironhaven 3y ago
      Unless you can use an off the shelf http client to make ssh connections I can’t think of a benefit for using http headers vs non-http key value pairs.
• wslh 3y ago
  Is there a security audit for this code?
• cvalka 3y ago
  Why no support for mTLS? Certificate based authentication for clients is a must.
• anthk 3y ago
  Meh. OpenBSD does it fine. If not, Mosh works great on flakey connections.
• jedisct1 3y ago
  This is cool, but calling that SSH3 is not appropriate. It's an independent project, not a new version of the SSH protocol. Sure, it's "SSH3" and not "SSHv3". Still, introducing a confusion with something that could be an official protocol is not nice.
  • netsharc 3y ago
    I'm surprised no one's opened an issue on their repo and that no brigade has opined with lots of comments and emojis...
    • hddqsb 3y ago
      There is now an open issue: https://github.com/francoismichel/ssh3/issues/79 https://github.com/francoismichel/ssh3/issues/79
• Sleaker 3y ago
  What makes this any better than say, MOSH?
• JCharante 3y ago
  Oauth for ssh sounds annoying
• zelly 3y ago
  Seems cool but mosh already exists
• egberts1 3y ago
  SSH3 does not equate to SSHv2 over HTTP/3-QUIC.
• throwawaaarrgh 3y ago
  Throwaway's maxim: no new protocol works without HTTP
• skywhopper 3y ago
  This is a really cool project and a great idea that seems to be decently implemented. Calling it “SSH3”, however, is misleading at best, and misrepresents what the project is. Please consider choosing a better name.
• gsu2 3y ago
  This seems bad? - SSH3 is a bad name: this isn't a successor to SSHv2 and will only cause confusion - The authors don't seem to understand that SSHv2 predates all of their chosen technologies, and provides "robust and time-tested mechanisms" they claim to be adding - How is "hiding your server behind a secret link" a feature? This is, at best, security through obscurity, which can be layered on any network protocol (e.g. https://en.wikipedia.org/wiki/Port_knocking); https://en.wikipedia.org/wiki/Port_knocking); this implies that the authors don't have much of a security background...? - ...Which explains why they think something as complicated as OpenID Connect is a good thing to add to SSH (i.e. https://security.stackexchange.com/questions/148292/why-is-oauth2-openid-connect-considered-less-secure-than-saml-ws https://security.stackexchange.com/questions/148292/why-is-o...) - The abstract in the linked paper seems to conflate SSHv1 and SSHv2; I couldn't really bring myself to read much past that In summary: this seems bad.
  • janosdebugs 3y ago
    I concur. They seem to have reinvented a part of the protocol without actually addressing many of the issues of SSH. The paper also doesn't bother to go into details on any the advancements that have been made to SSH since the original RFC, such as keyboard-interactive, GSSAPI, etc. > Some SSH implementations such as OpenSSH or Tectia support other ways to authenticate users. Among them is the certificate-based user authentication: only users in possession of a certificate signed by a trusted certificate authority (CA) can gain access to the remote server [12]. Available for more than 10 years, this authentication method requires setting up a CA and distributing the certificates to new users and is still not commonly used nowadays. Somebody had an agenda to make SSH look as bad as possible. You can implement OIDC authentication with keyboard-interactive, no need for HTTP/3 for that. However, it gets very tricky if you want automated / script access, so it doesn't solve the authentication problem. As an aside, Tatu Ylonen, the original author of the SSH protocol, published a paper in 2019 titled "SSH Key Management Challenges and Requirements"[1], which is an interesting read. It would seem the authors of this paper should have at least read it. [1] https://www.ylonen.org/papers/ssh-key-challenges.pdf https://www.ylonen.org/papers/ssh-key-challenges.pdf
  • _8j50 3y ago
    Your points are great but SSH is extensible so openid connect support doesn't mean much since you can do it with existing ssh. "Security by obscurity" is only a thing if you're relying on that mechanism for security. People already configure SSH port knocking as you noted. It can be considered attack surface reduction and is a good feature given they're not using a secret link for any security control. One benefit of their approach might be how you can use TLS pki now instead if setting up ssh-ca's. Potentially you would need to manage less pki. But a criticism I have is how http* has much more vulns and new attack techniques being developed all the time unlike ssh. I can imagine LFI or request smuggling on the same http/2 web server causing RCE via their protocol.
• apatheticonion 3y ago
  Interesting. Having HTTP/3 layered over the top, which I presume allows for SSL certificates to be applied to the connection, might result in the SSH connection appearing to observers as standard - uninteresting - website traffic. Assuming one could connect to an SSH server this way and tunnel ports, could this allow for a means to bypass China's GFW? China's firewall allows http and https connections through however VPNs, SSH and similar are detected upon connection and blocked on demand. Hiding a VPN connection by tunneling to a remote SSH server over HTTP/3, forwarding the VPN port and connecting to it might fly under the radar as it could be perceived as regular web traffic. Would be an interesting thing to try.
• zlg_codes 3y ago
  [flagged]
• Bu9818 3y ago
  For faster session establishment in OpenSSH consider ControlMaster in ssh_config(5), which multiplexes multiple sessions in one connection instead of creating a new connection for each session.
  • mynameisnoone 3y ago
    # ~/.ssh/config # Place at the *End-of-file* Host * ControlMaster auto ControlPath ~/.ssh/sockets/%C.sock ControlPersist 600 ServerAliveInterval 60 ServerAliveCountMax 10 IPQoS throughput TCPKeepAlive yes # :: Security Exception :: Purposeful for UX usability of machine-to-machine hops ForwardAgent yes # ssh-audit recommendations https://www.ssh-audit.com/hardening_guides.html # CASignatureAlgorithms sk-ssh-ed25519@openssh.com,ssh-ed25519,rsa-sha2-512,rsa-sha2-256 HostKeyAlgorithms sk-ssh-ed25519-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.com,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,sk-ssh-ed25519@openssh.com,ssh-ed25519,rsa-sha2-512,rsa-sha2-256 HostbasedAcceptedAlgorithms sk-ssh-ed25519-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.com,sk-ssh-ed25519@openssh.com,ssh-ed25519,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-512,rsa-sha2-256-cert-v01@openssh.com,rsa-sha2-256 PubkeyAcceptedAlgorithms sk-ssh-ed25519-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.com,sk-ssh-ed25519@openssh.com,ssh-ed25519,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-512,rsa-sha2-256-cert-v01@openssh.com,rsa-sha2-256 KexAlgorithms sntrup761x25519-sha512@openssh.com,curve25519-sha256,curve25519-sha256@libssh.org MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr # GSSAPIKexAlgorithms gss-curve25519-sha256-,gss-group14-sha256-,gss-group16-sha512-
    • ColCh 3y ago
      looks like there is no Compression=yes ?
• kiitos 3y ago
  The interesting thing here isn't so much the improved latency or whatever, it's the ability to ssh from a client that's on a network which restricts access to anything other than 80/443
• xg15 3y ago
  It's an interesting project, but I think a clarification would be important: Is SSH3 supposed to be "SSH-over-HTTP" that happens to use QUIC as a transport, or is it "SSH-over-QUIC" that happens to use HTTP as an auth/adressing layer? The difference is not just philosophical, it also has practical implications, in particular what part of the different protocols (SSH, HTTP, TLS and QUIC) clients, servers and intermediates are expected to implement and which can be left out. E.g., if it's "SSH-over-HTTP", I'd expect the protocol to work well with HTTP proxies and application servers and I'd expect to be able to run a SSH3 server and a regular HTTP server on the same port. On the other hand, I'd expect features that require precise control over the low-level QUIC connection - like UDP port forwarding and session resumption - to be less reliable. If it's "SSH-over-QUIC", the expectations would be the opposite: That you can treat QUIC (and TLS) as an integral part of the protocol, in the same way that the encryption, auth and transport layers in standard SSH are seen as an integral part of SSH. However then the server should generally be deployed as a standalone process on a separate port and should not be considered a fully compatible HTTP endpoint. That might diminish the "stealth" ability of the protocol a bit. Or to sum it up, which parts of the protocol stack would an SSH3 client or server be expected to provide by themselves and which parts would be delegated to the OS/infrastructure/intermediaries etc?