The Lair

Remember that whole fuss about public key cryptography? The premise is really simple. What it means for most of us is – never type in an ssh password again, your public/private keys should seamlessly handle all the nasty security bits. So, today – I found myself wanting to do something like that described here.

Simple right? I had a private key generated which I used for code I write in my spare time. Now I needed another private key. Yes, another one – because a few people reading commit logs at a very serious bzns organization might wonder who the hell drac is – and why his commits are appearing in their top-secret git repository.

Generate another private key. Simple.

ssh-keygen -t rsa


Mail the just-generated public key off to the guy setting up the repository and all is well. Except it wasn’t. Because I find that multiple invocations of ssh-keygen generate the same public/private keypair. Yup, generate a keypair for drac AT this domain. Invoke ssh-keygen again, fully expecting a different pair of keys to be created for [real name]. Umm. No. Same key.

I don’t know yet if this is a bug, or expected behaviour for ssh-keygen. Or if it is merely a quirk/bug of the ssh-keygen bundled with msysgit. In any case, I was surprised.

And if none of that made any sense to you folks, never mind. Tomorrow, I’ll tell you how I did some git ninja work. Do turn up, won’t you?

yes, wonkey = one key. I’m feeling particularly creative today

Had an interesting problem to solve over the weekend – how to get RMI to work across a restrictive firewall.

Not an uncommon occurence, you might think – there is a FAQ on the topic. In the FAQ item, there is talk of HTTP encapsulation and all manner of weird and wonderful things. Ah, but you see, I don’t really want to run a webserver to get two RMI aware processes to talk to one another, do I ? If I wanted to use HTTP, I would have done that in the first place. WebDav anyone ?

So, no… the FAQ doesn’t really seem to address the problem in the way I wanted it solved.

Now what ?

A quick examination of the endpoint connections made by RMI revealed some more information – RMI always connects to port 1099, the rmiregistry… Thereafter, it uses a variable (negotiated) port number, much like FTP. Has anyone tried to tunnel FTP through a firewall ? No, it’s not fun. There’s a reason for weird things like PASV FTP. Clearly, the RMI people hadn’t figured out that explicitly specified connection endpoints were a good idea, at least when it comes to negotiating opening ports with a suspicious and paranoid firewall admin.

First step: I had to write a RMISocketFactory and setup the connections to always use one or more of ports 3801, 3802, 3803. That takes care of incoming calls. Now, one quick SSH forwarding later, I could get incoming messages through the firewall.

Outgoing ? This is where it got interesting. OpenSSH (and indeed, other ssh clients for all I know) has an interesting command line switch, -D.

This works by allocating a socket to listen to port on the local side, and whenever a connection is made to this port, the connection is forwarded over the secure channel, and the application protocol is then used to determine where to connect to from the remote machine. Currently the SOCKS4 and SOCKS5 protocols are supported, and ssh will act as a SOCKS server.

Ye gods. SSH can act as a socks server. Well, RMI can use a socks server to send outgoing calls through a firewall. Anything in Java that uses ServerSockets can use Socks to communicate.

Yeah. That seemed like it would work. And so it did. Two ssh invocations and one RMISocketFactory subclassing later, RMI packets were humming through the firewall.