I must be missing the point here somehow. From my simple mind I think that two things would be needed - first a mod, e.g., mod_sshd, or better an addition to mod_auth and mod_proxy so that a URL could be used to initiate contact to an sshd server elsewhere. The mod_auth part could/should be used to verity the credentials to used - basically setting up the VPN between ssh and httpd as ssh; the httpd server would setup it's own separate connection with the target sshd - with mod_proxy_logic - to verify that the httpd server can and will make a connection. Lastly, to prevent a continous man in the middle the original ssh client would make a second connection to establish ciphers, mac and kex via the two connections using the httpd as man-in-the-middle. This is awkward - I apologize - but what I think I am saying is that the goal is to setup something similar to an IKE tunnel - except the destination end-point leap frogs. To maintain encryption the ssh client will need to have a secret key with the target sshd - but to communicate it would need to encrypt twice - once for the 'hop' to the httpd server - who would undo that envelope and then send this encrypted message forward - functioning more as a router because it would not necessarily need to encrypt it again to get it there. The reply, assuming the httpd is not re-encrypting the encrypted message, is a bit more complex - i.e., needs openssh cooperation/understanding. "Somehow" sshd knows there is a proxy in the middle so it also does a double encryption - initial for the other "endpoint", and one for the first hop back to the httpd (let me call it) - mid-way point. Now - repackaging/encryption will be needed so the ssh client is able to recognize IP endpoints. I suppose - there could also be requirements where re-encryption by httpd is always needed - because of firewall rules only permitting the httpd IP address endpoint to pass through ipsec/ipfilter rules. Personally - under the assumption it can be done - I doubt I would want my httpd server to be handling this kind of load. Nor would I want to be the one - depending on a role, e.g., to say to my boss, or to say to a customer buying security consultation services that "openssh is great - we have added stuff that can be used to bypass firewalls. If this kind of tunneling is something I want to support I would examine using openssh - ASIS - plus a virtual machine aka "jailed process" with it's own IP address and just use normal openssh tunneling from port X (e.g., X==80) to somewhere else. my 3 and half bits :-) On Fri, Jan 30, 2015 at 8:39 AM, Phil Lello <phil@xxxxxxxxxxxxxxx> wrote: > On 29 Jan 2015 21:53, "Ángel González" <keisial@xxxxxxxxx> wrote: > > > > On 29/01/15 21:15, Alex Bligh wrote: > >> > >> Be frightened: > >> > > https://chrome.google.com/webstore/detail/secure-shell/pnhechapfaindjhompbnflcldabbghjo?hl=en > >> > > That's a ssh client implemented in chromium, not a web server acting as > sshd. However… > > «Secure Shell also knows how to connect to an HTTP-to-ssh relay that was > built inside Google. Unfortunately > > that relay isn't open source, and Google > doesn't maintain a public pool of relays» > > -- > > http://git.chromium.org/gitweb/?p=chromiumos/platform/assets.git;a=blob;f=chromeapps/nassh/doc/faq.txt > > > > > > > > > > Phil wrote: > >> > >> My main motivation is that it is generally easier to route HTTP across > >> multiple corporate firewalls than getting ports opened for ssh (even if > it > >> is an embedded sshd such as in gerrit rather than an actual shell). > > > > It will depend on how picky the firewalls are. You may prefer to embed it > into a https stream, > > such as using a proxy command of socat - openssl-connect:%h:%p > > > That's certainly worth considering. However, my focus when posting was more > motivated by defining a standard for ssh - over - web sockets, such as > ws://host/path, along with a standard (as opposed to proxy command) > implementation. > > I think in intranet environments tunneling over HTTP is good so that > firewalls can inspect session setup/endpoints; in public environments I'd > go for HTTPS to prevent precisely that. > > So, would a patch to the client to support hostnames as ws:// or wss:// be > a welcome addition? If so, should a reference server be included too, given > that I would be doing this as an apache module? > > Phil > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev@xxxxxxxxxxx > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
