search

francoismichel / 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/
https://arxiv.org/abs/2312.08396
Apache License 2.0
3.29k stars 84 forks source link

"virtual hosts" #43

Open mzhang28 opened 11 months ago

mzhang28 commented 11 months ago

Hi, found this through HN. Is there any plan to support "virtual" hosts the way HTTP servers do? This is a shortcoming of SSH that I've run into time after time, because SSH doesn't allow me to indicate what host I'm trying to connect to.

It seems like with the cert setup, the work is already half done, the biggest part of the work I'd imagine is just a way to specify multiple host names with multiple certs.

I'd be interested in contributing if this is something you'd like to see.

kolobus commented 11 months ago

It should probably work with reverse proxies like nginx and traefik taking care of vhosts.

mzhang28 commented 11 months ago

ah i didn't think of that. i'll give that a try and report back :)

kolobus commented 11 months ago

Please also post here use case in which you want single instance ssh3-server to respond differently on different vhosts. Curiosity is killing me :)

gnanet commented 11 months ago

Please also post here use case in which you want single instance ssh3-server to respond differently on different vhosts. Curiosity is killing me :)

just a thought: if H3 is able multiplexing, a simple website and a sshv3 could share the same H3 server, and by hostname it could decide which service is requested. or do i misunderstand the HTTP3 part?

francoismichel commented 11 months ago

Yes it is a really cool feature that we would love to provide out-of-the-box.

If one wants to mux it in an existing Go app, I am 80% sure that is can already easily be achieved by wrapping the ssh3 handler below in a public API function. Note that currently it is best to dedicate the entire H3/QUIC connection to the current SSH3 conversation as SSH3 currently hijacks every received H3 datagram because quic-go seems to only allow doing that.

Doing that in a more general setup behind a proxy might be achievable as well but it requires one change: currently, privkey auth currently sign TLS exporters that are entirely linked to the current TLS session and we need to change that to have privkey auth going through proxies. With privkey authentication, bearer tokens are not really bearer tokens... I'll look at that once I publish the protocol specification, it is probably just a matter of time.

ei-grad commented 11 months ago

Curiosity is killing me :)

What about getting shell into the containers / pods / namespaces? Though, vhosts functionality is not the best way to do such things, maybe path or query parameters could be a better match. And vhosts may be better suited for proxing to several different hosts.

kolobus commented 11 months ago

What about getting shell into the containers / pods / namespaces? Though, vhosts functionality is not the best way to do such things, maybe path or query parameters could be a better match. And vhosts may be better suited for proxing to several different hosts.

If I understand correctly - those will be different instances of ssh3-server in pods and reverse proxy is exactly what decides which vhost goes to which container. I don't see possibility single ssh3-server to be ssh to anywhere except host it is running on.

mpiraux commented 10 months ago

FYI there is now #89 that has work towards this :)

francoismichel commented 10 months ago

Also, you can already setup ssh3 vhosts using nginx or haproxy for instance, but it currently has to be done without decrypting the QUIC connection, so it must be done based on the TLS SNI. My answer to #97 explains how to do that with nginx (version >1.25.3), it will probably be similar with other servers/proxies that parse the QUIC SNI.