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. 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 :-) On Fri, Jan 30, 2015 at 8:39 AM, Phil Lello <phil at dunlop-lello.uk> wrote:> On 29 Jan 2015 21:53, "?ngel Gonz?lez" <keisial at 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? > > ?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 > > > 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. > > 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 > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev >
On 30 Jan 2015, at 08:28, 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.See https://github.com/abligh/apache-websocket/tree/master/vncproxy 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
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
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 >