I thought Perl could be a good starting point to tinkering, especially since btrott's OpenPGP is available. So, perhaps his client is a good place to start, since the actual transport is the same in both directions.

As for distributing the crypto, encrypt it using OpenPGP and post the key too. Only someone who already has access to that technology can read it. Or does that assume the feds can think logically...?

—John

If you're going to base an "application-level communication system" on it, why not just use SSL instead of SSH? If you don't need the "actual sshd features" (assuming you mean user authentication and command execution), I would guess that SSL is a better fit. To have an SSHD under Win32, you have to hack a unix-y authentication somehow, which seems like it could be a frustrating can of worms to open, especially if all you need is an encrypted channel for communication.

SSH is a much cleaner spec, separating the main building blocks architecturally better than SSL/TLS does. It is also designed for multi-channel multiplexing of communications over one established connection. It supplies compression (TLS has a placeholder for the concept but never did it) and encrypts the meta-data too, not just the payload.

SSH spec includes OpenPGP authentication. That's easier to work with than X.509 stuff! In the stuff I'm doing at work, authentication is a main issue. The built-in stuff between IE and IIS is not right for us. Using the cryptoAPI primitives or even the schannel stuff in Windows with callbacks to do the authentication and other details might be easy enough, but the application would then have to add another layer to that, to multiplex several channels. That's already part of the basic SSH protocol.

As for grafting unix-y authentication onto SSHD, the way Mark Bradshaw's port works requires a UNIX password file to be built, but it actually accesses the NT account data to log on when spawning the remote shell.

What I'm designing is basically a secure tunnel. One socket is used, but SSH-like port forwarding is being done on each end so the apps think they are using various sockets. The main tool will establish the tunnel, and auxilary tools will piggyback on the connection.

Basically, the client side and the actual transport part of the server side is exactly what I need. I just don't need the rshell as a built-in application service. I'll customize the authentication rules, but SSH protocol is very extensible in this area.