An alternative to `ProxyCommand'

[Tomi Ollila]

Hi

In last 2 mails I've been discussing of options how to best create a
feature I need, doing some special pre-handling of a communication
link until ssh will take over.

Now I probably understand the directions where ssh is not wanted to 
evolve, and been thinking how the features I'd like to see ssh
support (either directly or indirectly) could be implemented.

So, this is the latest and (IMHO) neatest.

An alternative to ssh option ProxyCommand that would work like the
following:

1) ssh creates the network socket and connects to the peer.

2) If this option (for which I don't know a good name ... yet) is used,
   ssh will launch the program associated with it. The first argument
   to this program will be the file descriptor of the network socket
   that is used for communication.

3) ssh will go to wait(), and when this launched program exits, will
   continue normally in ssh identification procedure and so on.
   While ssh is wait()ing process to exit, this process can read/write
   to stdin/stdout normally (it it wants to do so).

This way ssh can do all the same security checks that it could do when
working in "normal" mode, since it has access to the network socket.
Also, the launched program has access to that socket and therefore may
query it if it wants to know something -- passing the hostname with %h
might still be useful...

This option could be used in configuration file as the ProxyCommand
-option, allowing ssh/scp/... work as with it. Only a bit more effective
since there will be no process context switching and relaying the data.


ProxyCommand can add `SSH-...' string to the stream going to the ssh
process if necessary (it has read such data from network connection). 
W/ this new system this cannot be done. This is no problem, however --
the launched process can utilize recv(sd, buf, buflen, MSG_PEEK)
when reading the network socket, and adjust the receive buffer first
contain SSH-... when it exits (just as tt4ssh does).


Any opinions on this proposal -- c/sh/would this be done? I'll redesign
my tt4ssh to work with it if this is going to be implemented (and will
think a new name for it)... I could even implement this to ssh if it is
going to stay there in future releases also.


Tomi












Now that I possibly understand the model