On 30/01/15 08:39, Phil Lello wrote:
> It will depend on how picky the firewalls are. You may prefer to
embed it into a https stream,
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.
How would then programs (like vcs) that use a path like ssh://host/path
to mean "connect remotely using ssh" learn what to do with a
ssh-over-websocket url if you used ws:// there? IMHO ssh-over-websocket
should be ssh+ws://
(if at all desired)
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.
The first thing a websocket client would do if knowingly using a proxy
would be to open a HTTP tunnel with CONNECT.
If that's allowed by the proxy, you could as well use ssh-over-http
directly, instead of websockets.
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?
If any, I would make ssh connect directly to a ssh:// url, and for a
ssh+foo(\+[^:])*:// execute a 'foo' wrapper (eg. /usr/bin/tunnel.foo) as
ProxyCommand
I'm not convinced of the general usefulness of doing ssh over websockets
yet.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
