Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SSH3: SSHv2 using HTTP/3 and QUIC

github.com

Post reply on HN
Print view View original

181–190 of 206 posts

Re: SSH3: SSHv2 using HTTP/3 and QUIC

#181

Post by ironhaven »

wmf wrote: post #141
ironhaven wrote: post #100

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 HT…

You can use HTTP for authentication.

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.

Re: SSH3: SSHv2 using HTTP/3 and QUIC

#183

Post by tptacek »

overstay8930 wrote: post #166
Ayesh wrote: post #82

Earlier quoted context omitted.

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

It's crazy that SSHFP hasn't taken off, I don't think a single person on earth has ever verified a host key before attempting to connect, and deploying DNSSEC is trivial now that you can use ECC and ED25519.

* Deploying DNSSEC is obviously not trivial, as doing so has taken some of the largest companies on the Internet fully off the Internet for multiple hours, within the last year, so much so that it has become a running joke when companies have prolonged outages to suggest that DNSSEC is the culprit.

* There are still resolvers that can't handle Ed25519

* Being able to use Ed25519 was never the ops problem with getting DNSSEC rolled out!

* It's weird to assume that people would want to enroll their server integrity --- something that doesn't in any way depend on an Internet PKI designed to allow strangers to verify your identity, and that enlists de facto government support to make that use case work --- in a global PKI, especially when SSH already has a perfectly good certificate system that solves the same problem without any of the above liabilities.

What boggles my mind, and I mean this sincerely, not as snark, is that anybody in the entire world takes SSHFP seriously. Even if you stipulate that DNSSEC (and/or DANE) works, just arguendo, it's still a totally different use case than resolving SSH key continuity problems.

Re: SSH3: SSHv2 using HTTP/3 and QUIC

#184

Post by gonzo »

ironhaven wrote: post #181
wmf wrote: post #141

Earlier quoted context omitted.

You can use HTTP for authentication.

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.

Looks like http(s).

Re: SSH3: SSHv2 using HTTP/3 and QUIC

#185

Post by ReK_ »

adontz wrote: post #133
sargun wrote: post #128

Earlier quoted context omitted.

You can already use certificates to login via SSH. Usually you setup your own certificate authority and sign your own certs because they need special attributes.

SSH certificates (I encourage using them!) are not x509, absolutely incompatible.

You're thinking of SSH keys, which are not certificates. SSH certificates are indeed x.509: https://datatracker.ietf.org/doc/html/rfc6187

Re: SSH3: SSHv2 using HTTP/3 and QUIC

#186

Post by ChoHag »

ironhaven wrote: post #100

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 HT…

[dead]

Re: SSH3: SSHv2 using HTTP/3 and QUIC

#187

Post by ChoHag »

georgyo wrote: post #31

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…

[dead]

Re: SSH3: SSHv2 using HTTP/3 and QUIC

#188

Post by mynameisnoone »

Bu9818 wrote: post #178

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.

    # ~/.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-

Re: SSH3: SSHv2 using HTTP/3 and QUIC

#189

Post by anticensor »

egberts1 wrote: post #125
ironhaven wrote: post #100

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 HT…

Do you want to maintain a state machine for each QUIC-SSH session 1-N pairing? Or worse, M-N pairing?

Why not have 1:1 relationship between QUIC connection IDs and open SSH sessions?

Re: SSH3: SSHv2 using HTTP/3 and QUIC

#190

Post by anticensor »

tengwar2 wrote: post #168
unilynx wrote: post #138

Earlier quoted context omitted.

I doubt QUIC is easier than TCP to build on. But it's much easier to get your new protocol through firewalls and other middleware when using port 443 than trying to introduce a new port (or worse: a new protocol number)

Which sounds like more of a disadvantage if you are running a firewall.

If your firewall drops unknown protocols, then it is broken. Internet is designed to be default-open, not default-closed.
Post reply on HN