SSH Over HTTPS While Serving HTTPS WebSite

Hey, folks! I use this blog also as a placeholder for little tidbits of info I find out on the net.  I stumbled across the following information for setting up an HTTPS proxy using Apache that allows a connection to a second port (e.g. for an SSH connection), while still allowing Apache to serve HTTPS requests on the same port  :

http://blog.chmd.fr/ssh-over-ssl-a-quick-and-minimal-config.html

Since most who visit here are already familiar with Apache's HTTPD server, I won't go into all the gory details.  If there is an unanswered question, visit the above link.

First, make sure you have the proxy module loaded!  This is a must, or you will receive errors when starting.  Next, open your SSL configuration that you want to allow the proxy on, and add the following :

ProxyRequests On
AllowConnect 139
<Proxy *>
    Order deny,allow
    Deny from all
</Proxy>
<Proxy 127.0.0.1>
    Order deny,allow
    Allow from all
</Proxy>

This essentially allows the proxy headers to tell Apache what you want to connect to, but limits it to only the localhost connection on port 139.  All other proxy requests (unless you've added more) will be denied.  Make sure you test it.  If it's failing to fire up for you, try doing it over the unencrypted (HTTP) connections instead (you will have to change the Apache configs for that), and watch what it is doing.

For the client side, you can connect to the proxy tunnel by installing the proxytunnel package, then using the command :

proxytunnel -E -p example.com:443 -d 127.0.0.1:139 -q

If you are having problems connecting to the tunnel, change the -q to a -v (quiet to verbose), and try it again. If you are not doing Samba access, but sending it to SSH, you can connect to the tunnel, add the following stanza to your $HOME/.ssh/config file :

Host example.com
    ProxyCommand proxytunnel -q -E -p example.com:443 -d 127.0.0.1:139
    DynamicForward 1080
    ServerAliveInterval 60

This should allow you to run the ssh command where it sets up the connection for you.  Try it out!  Again, I'm not the expert here, I simply pilfered this information from http://blog.chmd.fr/ssh-over-ssl-a-quick-and-minimal-config.html (and there is much, much more available from that link!

Apache - proxiing to simple proxy to allow viewing of authenticated data

In Apache, we can enable the proxy module to allow our web server to send a request to another location, and we serve the result.  To do this quickly, simply enable the proxy modules you need :

LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_connect_module modules/mod_proxy_connect.so
LoadModule proxy_ftp_module modules/mod_proxy_ftp.so
LoadModule proxy_http_module modules/mod_proxy_http.so

Once enabled, you can then create the proxy section. Please note that the following configuration is for an example - do NOT use it without hardening who has access to your proxy!  The config :

<Proxy *>
Order deny,allow
Allow from all
</Proxy>
ProxyPass / http://www.google.com/

Again, note that this will create an open proxy, and that is bad if you don't control who can access what, because you will be the one left holding the bag if they request illegal material. You have been warned!

This works great for most things, but let's presume for a minue that you wanted to serve a page from an HTTPS connection, no matter how it's requested from our web server. We need to enable SSLProxyEngine. If we are using self-signed certificates from that location, you might have to also add "SSLProxyCheckPeerCN off", e.g. :

SSLProxyEngine On
SSLProxyCheckPeerCN off

Let's toss in two more criteria. First, let's presume that you want one subsection of your site to be served from the local filesystem.  We can disable the proxy for a location by adding another proxy pass :

ProxyPass /local/ !

Now, for the second part, let's presume we have a chunk of the proxy that requires authentication.  In this case, we don't want to present the real user with the password pop-up, so, how do we do this?  Web browsers utilize a basic authentication using a series of headers, WWW-Authenticate, and Authorization.  The WWW-Authenticate is a response header that triggers the browser to authenticate the request.  The browser pops up the username/password dialog box, and then uses that information to generate an Authorization header.

Since we really don't need to worry about the WWW-Authenticate header, we can simple inject a permanent Authorization header into the system.  It's done with the RequestHeader directive, similar to :

<Location /svn/trunk/>
RequestHeader set Authorization "Basic dXNlcm5hbWU6cGFzc3dvcmQ="
</Location>

Now, here is a problem. How do we know what to put with the Authorization header?  Looking at the value that follows Basic, it looks like a MIME Base64 encoding.  Feeding it through a simple perl command, we can decode it and find out that it is indeed a Base64 encoding in the format of "username:pass".  We can figure out what we need by installing the MIME::Base64 perl module and running :

[username@hostname ~]$ perl -MMIME::Base64 -e "print encode_base64('username:password');"
dXNlcm5hbWU6cGFzc3dvcmQ=
[username@hostname ~]$

This will inject an authorization header into the proxied request.  Hopefully, this little cheat sheet will be of assistance to someone.

Main Website Revamp

Time for a technology-related post.  I finally finished revamping the layout for the main website.  Yes, the redesign took 6 MONTHS.  It's ridiculous.

The problem comes when I do work at work, and when I get home, I am done with computers.  I'll keep on handling the content changes as the domain is converted to my own personal playground.  But, it is definitely on it's way.

Still the site that advertises consultation that is being migrated, I will honor consultations that existed prior to 6 months ago on that owner (but not before that one), plus, new consultations are accepted until the site is migrated.

So, there you have the status.