legacy.not404.com

While working on some projects at a large financial institution, I had a need to access my Internet Servers for various reasons.  While I had been granted the typical Internet Access (Web Access) through the company's Microsoft Proxy Server to download files and patch updates, the proxy server was not configured to allow me access to the most useful protocol of all, OpenSSH.

After several days of trying various solutions, I settled on a quick and dirty (and yet, surprisingly convenient) solution:  NTLM-Authenticate myself against the Microsoft Proxy Server so it will allow me to make an outgoing connection; and configure OpenSSH on one of my Internet Servers to listen in on one of the "Approved" ports that Microsoft Proxy Server will allow:  Port 80 (http), Port 443 (https), or Port 563 (snews).

With that approach in mind, and not wanting to reinvent the wheel, I took an already excellent SSH Proxy tool written by Shun-Ichi Goto, commonly known as connect.c.  It's a great tool that does the job for getting through most other http-proxy servers.  I simply added some NTLM Authentication support to his work, and was soon able to initiate ssh connections through the Microsoft Proxy Server that was troubling me.

Credits

The SSH-NTLM Tunnel Creator is an enhanced version of connect.c, written by Shun-Ichi Goto. I have added NTLM Authentication support (aka "Integrated Windows Authentication") to this tool, by combining existing code from various Open-Source Projects, and adding some glue-work of my own:

• The actual NTLM routines were written by Daniel Stenberg (of Curl and libCurl fame), and donated under the GPL to the Neon Project.
• The DES cipher was extracted from GnuPG (gnupg-1.4.1), so that this can be compiled without requiring OpenSSL to be installed.
• The base64 codec was written by myself. It's more of a human-friendly source code implementation, not the bit-banging mess you often see in other base64 implementations.

Yes, It Works With Cygwin's SSH

It now works fine when compiled to run under cygwin. In fact, I've recently standardized on a WinXP desktop, and use Cygwin's rxvt as a terminal emulator. From within rxvt, I can use ssh and scp just like any other command-line tool in the suite.

The nice part about Cygwin is their built-in X-server, whcih can be started up on demand. While tunneled through Microsoft Proxy Server, ssh forwards the X session right to the X-server running on my WinXP desktop. Sweeeeeet! Now I have the best of all worlds on my WinXP desktop.

Recent Changes

• Fixed a bug with the static DES routines, now you can compile this without having OpenSSL installed. Yay!
• Fixed a bug in the NTLM-Handshake - it wasn't resetting the socket, so you ended up having only ONE chance to get the NTLM password correct. You now have more than one chance to enter the correct NTLM password. :o)
• Fixed the Makefile so that it compiles under Cygwin now. Yay!
• Cleaned up the sources, and updated the config-example file.
• Added a "keep-alive" setting to the SSH ProxyCommand configuration file, so that the tunnels no longer break because of inactivity timeouts.

Known issues

None. If you find any bugs, please let me know by submitting a New Ticket above, as this seems to work fine for me. Thanks!

Why I Created This Tool

I created this tool for two reasons. First (and most important), I wanted to be able to connect to external machines. This is darn near impossible if you're behind a Microsoft Proxy, unless you've got a cool NetAdmin who will punch holes in the firewall for you. If not, only the standard web-browser outlets are available.

Fortunately for us, Microsoft Proxy's default configuration allows a direct pass-through -- if you can speak NTLM Authentication, that is. All you need to do is connect via Secure HTTP (Port 443), or Secure News (Port 563). Chances are, you've got root on your destination machine and can easily get your SSH Daemon listening on either of these ports.

The other reason I created this is to avoid the hassles and corporate red tape. Let's face it, NetAdmins are the guys who have to answer to the Big Boss if anything gets compromised. If they don't understand the risks involved with opening up their firewall/proxy, you're probably not going to get the help you need to get that firewall hole punched. It's way easier for NetAdmins to just shrug you off and deny your request. All-Righty, then! We'll just do this on the sly and operate in "stealth mode". We'll simply make SSH bend over backwards to appear like it's a standard Web Browser, connecting via MS-Proxy to a standard Web Server Port on the Internet. Unless the NetAdmin is *looking* for your traffic, nobody will be the wiser.

Benefits of this Tool

NO NEED TO BOTHER A NETADMIN. The last thing you need is to be placed on their "Watch List", having your usage patterns audited more frequently. :-p

YOUR CONNECTIONS ARE AUTHENTICATED BY USING A REAL LAN ACCOUNT. Arguably, you're not really circumventing anything in the company's Network Security Infrastructure. You're not punching a firewall hole, and you're not going through an insecure "open password" proxy. As far as the NetAdmin is concerned, this is a *GOOD THING* -- there's no extra maintenance burden on their behalf, and they can still control your access to the Internet by setting permissions on your LAN Account. And as long as you're not setting off any red-flags or tripwires, nobody will be the wiser anyway. Win-Win.

CONNECTIONS BLEND IN WITH NORMAL HTTP TRAFFIC. unless your proxy explicitly has a more liberal configuration, you'll need to connect to Port 443 or Port 563 in order to get out to the Internet. As long as your target SSH Daemon is configured to run on Port 443, your connection will generally blend in with normal HTTP traffic patterns. Connecting to Port 563 *might* raise an eyebrow if your NetAdmins are monitoring their logs, though.

THE FULL SUITE OF SSH FUNCTIONALITY IS AVAILABLE. This is a huge benefit -- instead of transmitting your sensitive file using plain-text protocols like FTP or HTTP, you can send over a secure channel using Secure Copy (scp).

Questionable and Unrecommended Ways to Use SSH with This Tool

Keep in mind that these may be considered "circumvention techniques", which can get you into hot water. You've been warned.

SSH provides a "Port Forwarding" function, that allows a local port to point to a service running on an external machine (outside the proxy). By port forwarding to an external open proxy, you can completely bypass any content restrictions that are enforced by your internal proxy server. Now you have a way to access your Web-Based Email and your pr0n subscription websites.)

Of course, this little bypass trick can be used for legitimate purposes. Suppose you need to debug your company's website from the perspective of an outside viewer. Instead of using a "Dialup" account from your office to use an ISP's connectivity (which I see far too often), you can just use port forward an external proxy so that it appears as an internal one. Set your web browser to use this, making sure you don't bypass the proxy for any local content. Now you have a way to test for "Broken Links" like "file://" URLs that may have been left behind by your brain-damaged web-creation tools.

User Feedback

Comment by Zed on Tue 24 Jan 2006 08:59:51 PM PST

works like a charm

thanks

Comment by anonymous on Thu 16 Feb 2006 04:31:02 AM PST

you bet it does!!!

Comment by anonymous on Mon 27 Feb 2006 02:12:01 PM PST

Can you add an example how to use it?

Comment by lalee on Mon 27 Feb 2006 06:37:20 PM PST

Under Linux and Cygwin, you can copy the included config-example into ~/.ssh/config . Then you can edit the configuration file, replacing "mydomain/laulee@proxy.mydomain.org:8080" -- "mydomain/laulee" gets replaced with your own NT Login-id; and "proxy.mydomain.org:8080" gets replaced with your proxy server's name and port.

If your SSH server is running on port 443, change the "Port 563" line to reflect that.

Once all that configuration is done, you should be able to do this:

• ssh -l root myserver.dyndns.org

You will be prompted for two passwords -- the first is your NTLM password to get through the NTLM Proxy Server; and the second is your actual password to get into "myserver.dyndns.org".

Let me know if this works for you, or if you need additional help. Thanks!

Comment by lalee on Mon 27 Feb 2006 06:39:07 PM PST

I also have Shun-Ichi Goto's original documentation mirrored here, for reference.

Comment by bobby on Wed 08 Mar 2006 06:11:45 AM PST

ERROR: (504) proxy is not allowed via xxx I keep getting this error, password is not yet asked, so it fails even before authenticating to the proxy

Comment by lalee on Wed 08 Mar 2006 12:57:28 PM PST

Are you trying to connect to an SSH Server on Port 563? If so, your administrators have probably locked down the proxy server a little harder than usual. In this case, you probably have little choice but to run your external-machine's SSH Server on Port 443. (Which should work, as it's the HTTP S port...)

If you're trying to connect to an SSH Server on something other than Port 563 or 443, the default settings of the proxy server will definitely deny access.

Comment by anonymous on Mon 24 Apr 2006 10:38:44 AM PDT

is there any windows precompiled version ?

Comment by lalee on Sun May 7 02:43:28 2006

Sorry, there's no windows precompiled version at this time. If installing the Compiler Tools in Cygwin is an obstacle, let me know (in the forums is preferred), and I'll put together a windows bundle.

Comment by anonymous on Fri May 12 14:02:55 2006

Are there plans for NTLMv2 support?

Comment by lalee on Wed Jun 21 18:51:50 2006

I haven't looked into NTLMv2 yet, sorry..

Comment by anonymous on Fri Jul 20 01:47:31 2007

Nice program. Question: is there anyway to automate filling in the proxy password ?

Comment by lalee on Fri Jul 20 03:02:00 2007

It's been a while since I've cracked open the sources for this project. From what I recall, my original intent was to have passwords typed in manually where needed.

I think you might be able to pass a Name:Password pair via the -H parameter (or corresponding section in the ssh config file), though I have not tried this personally:

mydomain/laulee:myPassword@proxy.mydomain.org:8080

The -H is one of the parameters that Mr. Goto (the original connect.c author) implemented for passing in authentication data for Socks5 proxies, and I don't recall changing anything about that parameter's handling.

In the worst case, you could always make a quick addition to connect.c here to accept a new command-line parameter or read a custom config-file of some sort. :-)

Comment by mike on Fri Oct 12 06:44:41 2007

Beautiful program!! I tried to compile it on mingw32 and I had success. This evening I will try to compile on my linux box too ^_My ambitious project is to add the code at putty utility (initially for my personal use, then if I have succes could try to contribute to putty project). For now I am on Heavy sea :-)

Comment by mike on Fri Oct 12 08:17:32 2007

In the las message i forgot to mention: looking at the code I discover that the program read from the environment the 2 variables HTTP_PROXY_USER and HTTP_PROXY_PASSWORD. Useful to automatic login (asked from anonyumous user above). bye

Comment by mike on Fri Oct 12 08:31:19 2007

In the las message i forgot to mention: looking at the code I discover that the program read from the environment the 2 variables HTTP_PROXY_USER and HTTP_PROXY_PASSWORD. Useful to automatic login (asked from anonyumous user above). bye