PuTTY wish ssh-server

This is a mirror. Follow this link to find the primary PuTTY web site.

summary: Write an SSH server based on the PuTTY code, for testing purposes
class: wish: This is a request for an enhancement.
difficulty: tricky: Needs many tuits.
priority: low: We aren't sure whether to fix this or not.
fixed-in: 1d323d5c804eaf7f8ac9e4a80702ded7b6c7bdd2 (0.71)

A lot of the code required to support the SSH protocol is very similar between an SSH client and a server. The ssh-connection protocol is perfectly symmetric in principle (though in practice clients and servers will accept a very different range of requests and channel types), the mathematics of Diffie-Hellman key exchange is symmetric (the order of messages in SSH kex methods is asymmetric, but all the really hard work is the same on both sides), and although the authentication protocol is completely asymmetric the underlying primitives of public keys, signing and signature verification are needed by both client and server (because what the client needs for authentication the server needs for dealing with host keys, and vice versa). And of course a lot of underlying machinery such as dealing with multiple network connections, OS handles, timers and so forth is needed equally by clients and servers.

PuTTY is a code base that already knows how to implement an SSH client, and therefore it wouldn't be too much work to implement a server based on the same code. The kex and auth code would have to be significantly rewritten, and there'd probably want to be some splitting-up of ssh.c into common, client-side and server-side pieces, but I don't think it would be infeasible in principle to build a server out of the pieces of PuTTY.

I don't mean to say that it would be a good general-purpose SSH server, that you could run on your Unix (or Windows) machine to allow your users to log in remotely. That would be a much larger piece of work. It would need a lot of new and difficult code (e.g. to interact with OS authentication systems like PAM), testing (on assorted different kernels and OS distributions) and security hardening; it would be foolish to think we could trivially dash off something that could compete with existing well-tested mature offerings like the OpenSSH server. (Though we could at least make it open Unix pseudo-terminals, by reusing the pty backend from pterm.)

No, when I say "SSH server" I just mean something that's protocol-compatible with an SSH client: something that PuTTY (or other clients) could connect to successfully and go through the motions of kex, auth, opening channels and transferring data. My vision of such a program is that it would be used for stunts and testing: it would be highly reconfigurable, and willing to use dark corners of the SSH protocol which are currently hard to test.

If we had such a thing, we could use it to build an automated test suite for the PuTTY client code, and make it do difficult and annoying things so we could check the client handled them correctly. Examples of things it might usefully test are:

requiring multiple sequential authentications during userauth
SSH_MSG_USERAUTH_PASSWD_CHANGEREQ
sending zero prompts in a keyboard-interactive request
confusingly changing the range of crypto primitives presented in a rekey
sending SSH_MSG_UNIMPLEMENTED at annoying moments
sending an assortment of things we don't support (channel requests, global requests, channel types, strange classes of extended data, unrecognised messages), to check that we refuse them in the correct way
interaction of channel closure with unanswered channel requests

It might also be useful as a test-bed for new protocol elements.

Another potentially interesting thing it might do would be to speak the simplified connection protocol used by PuTTY's connection sharing, so that it appeared to PuTTY clients as a sharing upstream but in fact was a complete server in its own right. This simplified connection protocol might also be useful in other specialist circumstances, e.g. communicating with virtualised systems which make it easy to get a single byte stream in and out of them but harder to do anything more complicated (e.g. a very locked-down User Mode Linux).

Finally, it would also make a handy debugging tool for probing the behaviour of other SSH clients, since we could make it produce packet logs in the same useful level of detail as PuTTY itself does.

None of the above constitutes a single really good reason to write such a server, but it's possible that between them they might add up to enough motivation to go to the effort. Perhaps.

Update, Oct 2018: the sort of server described here can now be built from the PuTTY code, which has been refactored to make this possible. It's called "Uppity". It interoperates with the PuTTY client, but is indeed not useful as a general-purpose SSH server. It comes with an SFTP server implementation. It's not very configurable yet, and we haven't built it into a test suite yet.

If you want to comment on this web site, see the Feedback page.

Audit trail for this wish.

(last revision of this bug record was at 2019-03-16 00:01:44 +0000)