mindterm - ssh with java applet

ssh is now almost the default way for remote login and management of a Unix/Linux box. Thanks to OpenBSD people for the great work and he great mind to open-source their work, OpenSSH is now shipped with almost all linux distros (I can’t think of any without) and built on most Unix flavors. It is even available on M$ Windoze: for open-sourced offerings, there is OpenSSH server within the full cywin enviroment, or some strip-down evsrion, like CopSSH, ...; recently there is also MinGW based offerring which doesn’t require cygwin1.dll (it is a nightmaire if you have multiple different versions of cygwin1.dll on your windows box). There is freeware product called freeSSHd as well but it is not open-sourced.

Put the availablity of ssh server aside, you also need some ssh client program to access an ssh server. On Unix/Linux, this is a non-issue. On windows there is open-sourced putty, as well as the ssh client program coming with openssh package (either cygwin1.dll based or MinGW+MSYS based).

But what if there is no ssh client installed on the system and you don’t have permission to install something on the box?

Well, mindterm comes to remedy. It can serves as java applets that you can download off from a website.

Say, you access a webpage which has the mindterm applet served (can be either in a popup mode or an embeded mode), with a java plugin enabled web browser, you can ssh into the box, without a ssh client program pre-existing on your local machine.

Notes:

1) mindterm is not open-sourced. The original version had source publically accessible though, but that version only supports ssh protocol version 1.

2) the ssh port, i.e., 22/tcp, still needs to be open on the server. You may access the applet on http port (80/tcp by default) , the applet itself still connects to the 22/tcp port from the client machine to the server. The port 22 is not tunnelled into the port 80 traffic. If you configure your ssh server to listen to a non-standard port, you need to change the mindterm settings accordingly.

apache: mod_rewrite/mod_proxy vs mod_proxy_html

With the native apache modules, mod_rewrite or mod_proxy, we can change strings in http headers, thus achieve the so-called proxy mechanism on the apache server. However, sometimes the changes of http request headers are not enough.

For example, I have experienced to archive an existing ZWiki site and re-host to another server. On the new server, I thought it would be nice to serve the ZWiki behind the apache server and users access it with a new virtual-host address.

The old ZWiki archive has links some of which can be changed with either mod_rewrite or mod_proxy; some other can not be changed with the apache native modules, however. Because those links are in the raw html pages. The apache modules only manupliate http headers. What can I do?

After a bit googling, I found a nice third-party module, mod_proxy_html, can come to remedy this. It does exactly what it says, changing the served html pages on the fly.

The compilation and linking to apache are very easy once you follow the documentation. The configuration is also a breeze. Arha.

apache settings for svnparentpath

Subversion http://subversion.tigris.org/ is a wonderful open-sourced version control system. With the mighty apache http://www.apache.org/, you can do very fine access control.

Here I record a small trick to deal with a problem when I set up apache+subversion.

For apache to view a subversion repository, you can either use SVNPath or SVNParentPath directive (you have to make sure the WedDAV is enabled). The former explicitly specify the location of a repository; the latter, as the name hints, specify the parent path of several repositories. This is quite handy when you want to host multiple repsitories. You just put all of them in the same directory and apache will pick them up automatically. So you don’t need to change the apache configuration everytime you add/delete a repository, if you use SVNParentPath over SVNPath.

But there will be a minor problem here. For example you decide to put repositories repo1, repo2, repo3, ... under /var/svn/ directory, and you set apache to browse them as http://www.mysite.org/svn/repo1/, ..., which is all fine, until you type http://www.mysite.org/svn/ in your browser address bar. Err, what have you got? An ulgy svndav error message. The reason is because /var/svn itself is not a repository, all its subdirectories are.

So what you can do to get rid of the scaring error message?

The apache mod_rewrite comes to rescue!

At least you have two choices here. Both use mod-rewrite to make apache serve the browser with a different url: (1) you rewrite the request with another page where all available repositories are listed (you’ll update that simple page whenever you add/remove a repository of course); (2) you redirect the request to a default repository you chosen (this works only when the default repository is not removed/renamed of course). You can choose whichever you like. But I found the second choice is suitable for apache virtual hosts where you don’t want a request escaping the virtual host scope.

Here is the sample part of /etc/httpd/conf/httpd.conf for the first option: (you browse http://www.mysite.org/svn/ and get a proxy page, http://www.mysite.org/svnrepo.html, where you can list all available repositories)

# subversion settings
 
     DAV svn
     # Set the parent path for all repositories.
     SVNParentPath /var/svn
     # Turn off all path-based authorization thus increase speed (default is on).
     SVNPathAuthz Off
     # For per-directory access control policy
     #AuthzSVNAccessFile /var/svn/httpaccess
     # Limit write permission to list of valid users.
     
         AuthType Basic
         AuthName "My Subversion Repository"
         AuthUserFile /var/svn/httpauth
         Require valid-user
     
     # Use mod_rewrite to serve a proxy page if unspecified.
     # Otherwise requests on /svn/ receive a DAV-SVN error as the directory
     # itself is not a repository - its subdirectories are.
     RewriteEngine on
     RewriteCond %{REQUEST_URI} ^/svn/$
     # can rewrite to a full url or better only rewrite to the requested uri
     # Also note the P or proxy flag here for proxy.
     #RewriteRule /svn/ http://svn.mysite.org/svnrepo.html [proxy]
     RewriteRule /svn/ /svnrepo.html [proxy]
 

and here is sample for the second option: (you browse http://svn.mysite.org/ and get redirected to the default repository, http://svn.mysite.org/software/)

# subversion settings

 # DocumentRoot has actually no effect here.
 # In fact it should be omitted to avoid confusion.
 #DocumentRoot /var/svn
 ServerName svn.mysite.org
 
     DAV svn
     # Set the parent path for all repositories.
     SVNParentPath /var/svn
     # Turn off all path-based authorization thus increase speed (default is on).
     SVNPathAuthz Off
     # For per-directory access control policy
     #AuthzSVNAccessFile /var/svn/httpaccess
     # Limit write permission to list of valid users.
     
         AuthType Basic
         AuthName "My Subversion Repository"
         AuthUserFile /var/svn/httpauth
         Require valid-user
     
     # Use mod_rewrite to set default repository if unspecified.
     # Otherwise requests on / receive a DAV-SVN error as the directory
     # itself is not a repository - its subdirectories are.
     RewriteEngine on
     RewriteCond %{REQUEST_URI} ^/$
     # can rewrite to a full url or better only rewrite to the requested uri
     #RewriteRule / http://svn.mysite.org/software/ [redirect=permanent]
     RewriteRule / /software/ [redirect=permanent]
 

Note:

1. In above samples, the basic apache authentication is used. Anonymous users can read the repositories but only authenticated users have write accresses. The authentication info is stored in /var/svn/httpauth which is managed by the htpasswd utility.
2. The above two samples assume you have webdav and svndav modules loaded appropriately. In most case the modules are enabled with a seperate apache configuration file, say, /etc/httpd/conf.d/subversion.conf, whilst I recommend to put the above configurations in the apache master confoguration file, /etc/httpd/conf/httpd.conf.

Update:

1. Since v1.3 and later versions of subversion (specifically, mod_dav_svn), the Apache httpd-based server can now display (in a web browser) the collection of repositories exported by the SVNParentPath directive: simply set ‘SVNListParentPath on’ in the apache configuration file. Therefore, the hack described in this page is now largely irrelevant. ;)

http, ssl/tls and virtual hosts

Traditionally http over ssl/tls has problems with name-based virtual hosts. There are several ssl certificates each of which is binded to one of the virtual hosts. Because the http requests sent over ssl/tls are encrypted, the server can not figure out which certificate to be used for the client-server hand-shake. For IP-based virtual hosts, this is not an issue as each certificate can be bind to an unique IP.

Mostly http over ssl/tls is implemented with a different port (443/tcp), rather than the standard http port (80/tcp). The conection is encrypted from the beginning. For this we even use a different URL prefix, i.e., https instead of http. This situation is similir to smtps for smtp over ssl and smtp the plain connection. However, smtps is now obslete and the stardard way for excrypted smtp connection is to upgrade a non-ecrypted smtp session to over tls. This way, both plain and encrypted smtp connections can be listened on the same port (25/tcp).

There is an internet standard to defaine how to similiarly upgade a plain http session to over tls. See RFC2817.

If this is implemented, the above-emtioned problem for name-based virtual hosts over ssl/tls will be naturally solved. Because the requested server name is in the plain-text http header, the encryption will be started after the connection is established.

Unfortunately this RFC isn’t widely implemented. The number 1 http server, apache implemented it in v2.1; the first stable version supporting this is v2.2, which was released in December 2005. I don’t care about IIS, but like many other cases (jpg2000, alpha rendering in png and CSS2 immediately come into my mind), Micro$oft holds technology advance again because of its dominant market share at the client side: IE doesn’t support it. Even my beloved mozilla firefox doesn’t support this feature (They planed to support RFC2817 in v3, see their roadmap).

There is another way around this issue: the server name indication (SNI) extension for TLS. This is one of various extenstions specified in another internet standard, see RFC3546.

The TLS SNI extension will also allow a client to tell the server which server is contacting, in the extended client hello. The traffic is always encrypted from the beginning as the https protocol is used, but the server understands which virtual hosts to be served after ssl handshaking.

It was note that Firefox 2 has already support RFC 3546. Check here. Also starting with IE 7, Micro$oft supports the TLS SNI extension.

On the server side, although apache v2.2 has native support for RFC 2817, the third-party module, mod_gnutls, has to be used for RFC3546 support. This module adds RFC3546 support to both apache v2.0 and apache v2.2.

Therefore for now, we’ll have to use apache (v2.0 or v2.2) plus mod_gnutls on the server side, and mozila firefox v2 or M$ IE 7 on the client side, for an SNI-enabled name-based virtual hosts over tls. After firefox v3 is released, we can use apache v2.2 with firefox v3, and enjoy plain and encrypted http connections on the same port! Can’t wait for that day.