SSH over websockets

[Nico Kadel-Garcia]

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

> * 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?

"When what you have is a hammer, everything looks like a nail."

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.