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 at dunlop-lello.uk>
wrote:
> On 29 Jan 2015 21:53, "?ngel Gonz?lez" <keisial at
gmail.com> 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 at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>