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@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@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@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@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@xxxxxxxxxxx, aes256-gcm@xxxxxxxxxxx,chacha20-poly1305@xxxxxxxxxxx [preauth] And at the client I see: C:\Users\Michael>ssh2 -d 2 michael@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@xxxxxxxxxxx, aes256-gcm@xxxxxxxxxxx,chacha20-poly1305@xxxxxxxxxxx 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@xxxxxxxxxxx, aes256-gcm@xxxxxxxxxxx,chacha20-poly1305@xxxxxxxxxxx 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@xxxxxxxxxxxxxxx> wrote: > > On Fri, Jan 30, 2015 at 8:28 AM, Michael Felt <aixtools@xxxxxxxxx> 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 > _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
