SSH over websockets

[Michael Felt]

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 michael at 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 michael at 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 michael at 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 michael at 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,aes128-gcm at openssh.com,
aes256-gcm at openssh.com,chacha20-poly1305 at openssh.com [preauth]

And at the client I see:
C:\Users\Michael>ssh2 -d 2 michael at 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,aes128-gcm at openssh.com,
aes256-gcm at openssh.com,chacha20-poly1305 at 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,aes128-gcm at openssh.com,
aes256-gcm at openssh.com,chacha20-poly1305 at 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?



On Fri, Jan 30, 2015 at 10:50 AM, Phil Lello <phil at dunlop-lello.uk> wrote:

>
> On Fri, Jan 30, 2015 at 8:28 AM, Michael Felt <aixtools at 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.
>> 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
> 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
>