Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
SSH over websockets
2,147 views
Skip to first unread message
Phil Lello
Jan 29, 2015, 3:02:14 PM1/29/15
to
Hi all,
I can't find a working archive search for this list, so please forgive me
if this has been discussed before.
Has any thought been given to supporting websockets in the ssh client? I'm
talking about solely using a websocket as the transport layer, and leaving
the actual protocol intact, as opposed to the (to me, frankly terrifying)
idea of allowing a web server to act as an ssh client to a regular sshd and
providing a terminal interface.
I'm weighing up the pros and cons of this idea in my own mind at the
moment, and whilst I like the idea for providing another transport to
services such as git-over-ssh, I can't help wonder if it would encourage
poor network security.
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). That
said, my main motivation is also probably the biggest reason not to push
this as a standard part of the ssh client.
I'm not subscribed to the list, please cc me in any responses.
Best wishes,
Phil Lello
_______________________________________________
openssh-unix-dev mailing list
openssh-...@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
I can't find a working archive search for this list, so please forgive me
if this has been discussed before.
Has any thought been given to supporting websockets in the ssh client? I'm
talking about solely using a websocket as the transport layer, and leaving
the actual protocol intact, as opposed to the (to me, frankly terrifying)
idea of allowing a web server to act as an ssh client to a regular sshd and
providing a terminal interface.
I'm weighing up the pros and cons of this idea in my own mind at the
moment, and whilst I like the idea for providing another transport to
services such as git-over-ssh, I can't help wonder if it would encourage
poor network security.
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). That
said, my main motivation is also probably the biggest reason not to push
this as a standard part of the ssh client.
I'm not subscribed to the list, please cc me in any responses.
Best wishes,
Phil Lello
_______________________________________________
openssh-unix-dev mailing list
openssh-...@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Alex Bligh
Jan 29, 2015, 3:21:21 PM1/29/15
to
On 29 Jan 2015, at 19:55, Phil Lello <ph...@dunlop-lello.uk> wrote:
> Has any thought been given to supporting websockets in the ssh client? I'm
> talking about solely using a websocket as the transport layer, and leaving
> the actual protocol intact, as opposed to the (to me, frankly terrifying)
> idea of allowing a web server to act as an ssh client to a regular sshd and
> providing a terminal interface.
https://chrome.google.com/webstore/detail/secure-shell/pnhechapfaindjhompbnflcldabbghjo?hl=en
--
Alex Bligh
Darren Tucker
Jan 29, 2015, 4:49:06 PM1/29/15
to
On Thu, Jan 29, 2015 at 2:55 PM, Phil Lello <ph...@dunlop-lello.uk> wrote:
>
> Has any thought been given to supporting websockets in the ssh client?
No, but you could implement it on the client side in a ProxyCommand. I
>
> Has any thought been given to supporting websockets in the ssh client?
dunno how you'd route from the websocket whatever to sshd on the server
side but I imagine it'd be possible.
--
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.
Ángel González
Jan 29, 2015, 4:54:36 PM1/29/15
to
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
> 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 into a https stream,
such as using a proxy command of socat - openssl-connect:%h:%p
Phil Lello
Jan 30, 2015, 2:44:45 AM1/30/15
to
On 29 Jan 2015 21:53, "Ángel González" <kei...@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…>
> 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
> «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
>
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
Michael Felt
Jan 30, 2015, 3:33:49 AM1/30/15
to
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.
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 :-)
Alex Bligh
Jan 30, 2015, 4:24:13 AM1/30/15
to
On 30 Jan 2015, at 08:28, Michael Felt <aixt...@gmail.com> wrote:
> 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.
which is a fork of apache-websocket to include a generalised tcpproxy.
Ignore the name vncproxy - it does some extra stuff for vnc if you want,
but will forward any tcp channel. Feel free to hack it about, then
forward it to 127.0.0.1:22.
--
Alex Bligh
Phil Lello
Jan 30, 2015, 4:55:53 AM1/30/15
to
On Fri, Jan 30, 2015 at 8:28 AM, Michael Felt <aixt...@gmail.com> wrote:
> 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.
> 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.
>
I may have explained myself poorly. The proposed apache mod would only
> 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.
>
exist as a reference implementation to verify that the client was working
correctly. I'm not thinking of supporting proxying from a webserver, other
than through traditional ssh netcat-style proxying. This would simply be a
mechanism to transport ssh traffic over websockets instead of vanilla TCP,
to allow ssh key-based authentication of a websocket connection. The
proposed use case is only for when the webserver is presenting an
application that wants ssh key-based authentication. Part of my motivation
is that I'd like to expose git or gerrit over websockets, and since these
already support ssh key-based authentication. rsync over websockets could
be good too.
As far as the security/political implications go, I fully agree it might
not work from a PR perspective, but I don't think this creates any more
issues than allowing sshd to run as a SOCKS proxy, or dynamically forward
inbound or outbound TCP.
For the reference implementation itself, I was thinking of using
https://github.com/disconnect/apache-websocket and providing a sshd plugin.
Phil
Michael Felt
Jan 30, 2015, 7:03:14 AM1/30/15
to
We may have just read in what we wanted to see ;)
* an interesting question - which got me thinking. But if I were in the
role of IT Dept. Manager I do not think I would want this, nor the other
links suggested as related.
It is very simple to verify if a client is working correctly - connect
locally. Perhaps what you mean is the client compatible - as I have been
discovering with my ancient ssh clients (one from 2002, something free I
love and cannot update) versus clients that can be updated. So, as far as
verification is concerned - to my reading this means you believe the normal
port should be reachable but you are not getting the (expected) response
from the client.
Something much simpler already exists - both the client (ssh) as the server
(sshd) support connectivity.
* for tcp connectivity, for years, rather than ping I use: "telnet host
port", e.g. telnet 192.168.129.70 22 - and as response I see
"SSH-2.0-OpenSSH_6.7"
* for regular connectivity issues - first just read the message - if any,
e.g. ssh mic...@192.168.129.70 has three possible results:
a) no response - perhaps a fw is blocking (or in this case, the demon is
not active)
C:\Users\Michael>ssh2 mic...@192.168.129.70
warning: Connecting to 192.168.129.70 failed: Destination Unreachable
b) there is an authetification error - thus, there is connectivity, but no
agreement on auth-handshake
C:\Users\Michael>ssh2 mic...@192.168.129.70
warning: Authentication failed.
Disconnected; key exchange or algorithm negotiation failed (Algorithm
negotiation failed.).
c) connection successful - prompt for password, or some successful key
exchange for auto-connect
C:\Users\Michael>ssh2 mic...@192.168.129.70
michael's password:
In closing, to validate connectivity, but not authentification just add -d
1 or -d 2 - at either end.
On my server (sshd -d) I am seeing:
Connection from 192.168.129.5 port 60743 on 192.168.129.70 port 22
debug1: Client protocol version 1.99; client software version 3.2.9 SSH
Secure Shell Windows Client
debug1: no match: 3.2.9 SSH Secure Shell Windows Client
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.7
debug1: permanently_set_uid: 202/201 [preauth]
debug1: list_hostkey_types: ssh-rsa,ssh-dss [preauth]
debug1: SSH2_MSG_KEXINIT sent [preauth]
debug1: SSH2_MSG_KEXINIT received [preauth]
no matching cipher found: client
aes128-cbc,3des-cbc,twofish128-cbc,cast128-cbc,twofish-cbc,blowfish-cbc,aes192-cbc,aes256-cbc,twofish192-cbc,twofish256-cbc,arcfour
server aes128-ctr,aes192-ctr,aes256-ctr,aes12...@openssh.com,
aes25...@openssh.com,chacha20...@openssh.com [preauth]
And at the client I see:
C:\Users\Michael>ssh2 -d 2 mic...@192.168.129.70
debug: Ssh2: License file not found, certificates & smart cards disabled.
debug: Ssh2: User config file not found, using defaults. (Looked for
'C:/Users/M
ichael/Application Data/SSH/ssh2_config')
debug: Connecting to 192.168.129.70, port 22... (SOCKS not used)
debug: Ssh2Transport: My version: SSH-1.99-3.2.9 SSH Secure Shell Windows
Client
debug: client supports 2 auth methods: 'publickey,password'
debug: Ssh2Common: local ip = 192.168.129.5, local port = 60743
debug: Ssh2Common: remote ip = 192.168.129.70, remote port = 22
debug: SshConnection: Wrapping...
debug: Remote version: SSH-2.0-OpenSSH_6.7
debug: OpenSSH: Major: 6 Minor: 7 Revision: 0
debug: Ssh2Transport: All versions of OpenSSH handle kex guesses
incorrectly.
debug: Ssh2Transport: Algorithm negotiation failed for c_to_s_cipher:
client list:
aes128-cbc,3des-cbc,twofish128-cbc,cast128-cbc,twofish-cbc,blowfish-cbc,aes192-cbc,aes256-cbc,twofish192-cbc,twofish256-cbc,arcfour
vs. server list : aes128-ctr,aes192-ctr,aes256-ctr,aes12...@openssh.com,
aes25...@openssh.com,chacha20...@openssh.com
debug: Ssh2Transport: Algorithm negotiation failed for s_to_c_cipher:
client list:
aes128-cbc,3des-cbc,twofish128-cbc,cast128-cbc,twofish-cbc,blowfish-cbc,aes192-cbc,aes256-cbc,twofish192-cbc,twofish256-cbc,arcfour
vs. server list : aes128-ctr,aes192-ctr,aes256-ctr,aes12...@openssh.com,
aes25...@openssh.com,chacha20...@openssh.com
debug: Ssh2Transport: lang s to c: `', lang c to s: `'
debug: Ssh2Transport: Couldn't agree on kex or hostkey alg. (chosen_kex =
NULL, chosen_host_key = ssh-dss)
debug: Ssh2Common: DISCONNECT received: Algorithm negotiation failed.
warning: Authentication failed.
Disconnected; key exchange or algorithm negotiation failed (Algorithm
negotiation failed.).
debug: Ssh2Common: Destroying SshCommon object.
debug: SshConnection: Destroying SshConn object.
So, if I read you correctly - my question now is: how is using a websocket
an improvement over what is already available?
* an interesting question - which got me thinking. But if I were in the
role of IT Dept. Manager I do not think I would want this, nor the other
links suggested as related.
It is very simple to verify if a client is working correctly - connect
locally. Perhaps what you mean is the client compatible - as I have been
discovering with my ancient ssh clients (one from 2002, something free I
love and cannot update) versus clients that can be updated. So, as far as
verification is concerned - to my reading this means you believe the normal
port should be reachable but you are not getting the (expected) response
from the client.
Something much simpler already exists - both the client (ssh) as the server
(sshd) support connectivity.
* for tcp connectivity, for years, rather than ping I use: "telnet host
port", e.g. telnet 192.168.129.70 22 - and as response I see
"SSH-2.0-OpenSSH_6.7"
* for regular connectivity issues - first just read the message - if any,
e.g. ssh mic...@192.168.129.70 has three possible results:
a) no response - perhaps a fw is blocking (or in this case, the demon is
not active)
C:\Users\Michael>ssh2 mic...@192.168.129.70
warning: Connecting to 192.168.129.70 failed: Destination Unreachable
b) there is an authetification error - thus, there is connectivity, but no
agreement on auth-handshake
C:\Users\Michael>ssh2 mic...@192.168.129.70
warning: Authentication failed.
Disconnected; key exchange or algorithm negotiation failed (Algorithm
negotiation failed.).
c) connection successful - prompt for password, or some successful key
exchange for auto-connect
C:\Users\Michael>ssh2 mic...@192.168.129.70
michael's password:
In closing, to validate connectivity, but not authentification just add -d
1 or -d 2 - at either end.
On my server (sshd -d) I am seeing:
Connection from 192.168.129.5 port 60743 on 192.168.129.70 port 22
debug1: Client protocol version 1.99; client software version 3.2.9 SSH
Secure Shell Windows Client
debug1: no match: 3.2.9 SSH Secure Shell Windows Client
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.7
debug1: permanently_set_uid: 202/201 [preauth]
debug1: list_hostkey_types: ssh-rsa,ssh-dss [preauth]
debug1: SSH2_MSG_KEXINIT sent [preauth]
debug1: SSH2_MSG_KEXINIT received [preauth]
no matching cipher found: client
aes128-cbc,3des-cbc,twofish128-cbc,cast128-cbc,twofish-cbc,blowfish-cbc,aes192-cbc,aes256-cbc,twofish192-cbc,twofish256-cbc,arcfour
server aes128-ctr,aes192-ctr,aes256-ctr,aes12...@openssh.com,
aes25...@openssh.com,chacha20...@openssh.com [preauth]
And at the client I see:
C:\Users\Michael>ssh2 -d 2 mic...@192.168.129.70
debug: Ssh2: License file not found, certificates & smart cards disabled.
debug: Ssh2: User config file not found, using defaults. (Looked for
'C:/Users/M
ichael/Application Data/SSH/ssh2_config')
debug: Connecting to 192.168.129.70, port 22... (SOCKS not used)
debug: Ssh2Transport: My version: SSH-1.99-3.2.9 SSH Secure Shell Windows
Client
debug: client supports 2 auth methods: 'publickey,password'
debug: Ssh2Common: local ip = 192.168.129.5, local port = 60743
debug: Ssh2Common: remote ip = 192.168.129.70, remote port = 22
debug: SshConnection: Wrapping...
debug: Remote version: SSH-2.0-OpenSSH_6.7
debug: OpenSSH: Major: 6 Minor: 7 Revision: 0
debug: Ssh2Transport: All versions of OpenSSH handle kex guesses
incorrectly.
debug: Ssh2Transport: Algorithm negotiation failed for c_to_s_cipher:
client list:
aes128-cbc,3des-cbc,twofish128-cbc,cast128-cbc,twofish-cbc,blowfish-cbc,aes192-cbc,aes256-cbc,twofish192-cbc,twofish256-cbc,arcfour
vs. server list : aes128-ctr,aes192-ctr,aes256-ctr,aes12...@openssh.com,
aes25...@openssh.com,chacha20...@openssh.com
debug: Ssh2Transport: Algorithm negotiation failed for s_to_c_cipher:
client list:
aes128-cbc,3des-cbc,twofish128-cbc,cast128-cbc,twofish-cbc,blowfish-cbc,aes192-cbc,aes256-cbc,twofish192-cbc,twofish256-cbc,arcfour
vs. server list : aes128-ctr,aes192-ctr,aes256-ctr,aes12...@openssh.com,
aes25...@openssh.com,chacha20...@openssh.com
debug: Ssh2Transport: lang s to c: `', lang c to s: `'
debug: Ssh2Transport: Couldn't agree on kex or hostkey alg. (chosen_kex =
NULL, chosen_host_key = ssh-dss)
debug: Ssh2Common: DISCONNECT received: Algorithm negotiation failed.
warning: Authentication failed.
Disconnected; key exchange or algorithm negotiation failed (Algorithm
negotiation failed.).
debug: Ssh2Common: Destroying SshCommon object.
debug: SshConnection: Destroying SshConn object.
So, if I read you correctly - my question now is: how is using a websocket
an improvement over what is already available?
Nico Kadel-Garcia
Jan 30, 2015, 7:38:28 AM1/30/15
to
On Fri, Jan 30, 2015 at 6:57 AM, Michael Felt <aixt...@gmail.com> wrote:
> We may have just read in what we wanted to see ;)
>
> * an interesting question - which got me thinking. But if I were in the
> role of IT Dept. Manager I do not think I would want this, nor the other
> links suggested as related.
>
> It is very simple to verify if a client is working correctly - connect
> locally. Perhaps what you mean is the client compatible - as I have been
> discovering with my ancient ssh clients (one from 2002, something free I
> love and cannot update) versus clients that can be updated. So, as far as
> verification is concerned - to my reading this means you believe the normal
> port should be reachable but you are not getting the (expected) response
> from the client.
>
> Something much simpler already exists - both the client (ssh) as the server
> (sshd) support connectivity.
> * for tcp connectivity, for years, rather than ping I use: "telnet host
> port", e.g. telnet 192.168.129.70 22 - and as response I see
> "SSH-2.0-OpenSSH_6.7"
Personally, I prefer 'nc hostname 22" or "ssh-keyscan hostname" or
> We may have just read in what we wanted to see ;)
>
> * an interesting question - which got me thinking. But if I were in the
> role of IT Dept. Manager I do not think I would want this, nor the other
> links suggested as related.
>
> It is very simple to verify if a client is working correctly - connect
> locally. Perhaps what you mean is the client compatible - as I have been
> discovering with my ancient ssh clients (one from 2002, something free I
> love and cannot update) versus clients that can be updated. So, as far as
> verification is concerned - to my reading this means you believe the normal
> port should be reachable but you are not getting the (expected) response
> from the client.
>
> Something much simpler already exists - both the client (ssh) as the server
> (sshd) support connectivity.
> * for tcp connectivity, for years, rather than ping I use: "telnet host
> port", e.g. telnet 192.168.129.70 22 - and as response I see
> "SSH-2.0-OpenSSH_6.7"
even "/usr/lib64/nagios/plugins/check_ssh -H hostname". The "telnet"
tool is a not an easily scriptable interface, and has become pretty
deprecated in modern Linux systems. Most of those are also available
in CygWin for Windows users.
I agree that the available command line tools are sufficient. I can
completely understand wanting to wedge it into web clients and web
servers, but I'm afraid personally of the security ramifications of
gluing it into an entirely distinct set of tools, many of which are
maintained by security casual software authors.
Ángel González
Jan 30, 2015, 10:48:50 AM1/30/15
to
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,
>
>
> > 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
> 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.
>
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.
>
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?
>
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.
0 new messages