ssh over udp (or: -L option listening for traffic with a UDP service?)

[Edward Peschko]

All,

A bit of background: I work on a QA API on a network that is very choppy (a
lot of network interrupts), and we use ssh to do a large part of this
automation.

This leads to some problems: ssh connections seem to be sensitive to
network state, becoming unusable if the choppiness reaches a certain
threshold, and either timing out or disconnecting if this happens.

Anyways, I stumbled across mosh (mobile open shell at http://mosh.mit.edu/)
which is *very* usable over choppy links. In fact you can disconnect
altogether, and reconnect hours after the fact and still be connected to
your host.

This led me to thinking - it has this flexibility because it uses a very
relaxed UDP policy for its connections - and for automation's sake I'd like
to use the same policy for sshd. Because everything is automated through
expect, there are no issues with responsiveness, or choppiness, so a large
buffer could compensate for a bad network.

At first I tried services like duat and tcpoverudp, which transparently
portforward traffic from udp to tcp. But these don't work because it looks
like the udp sessions don't hold the ssh connection well.

Which lead me to what I hope is a workable design. I'd like to setup
something that looks like the following:

Process 1: udp:local     <=> Process 2: udp:remote (forwards to)
tcp:ssh_client <=> tcp:ssh_server

Where the ssh communication is all local to the server, and the commands
are sent over a local UDP client to a UDP remote. The purpose of the ssh
client/server connection is to avoid the network choppiness and keep the
connection alive, and the purpose of the udp connection is to actually
handle the traffic and network choppiness.

So a couple of questions:

1. Is this doable?
2. Has anybody done it?

I see the '-L' option to ssh, so it looks like that's a hook to do this,
but AFAICT, the listening port is TCP and TCP only. Is it possible to make
it UDP and UDP only, and to put hooks in to have the traffic be handled by
a UDP protocol of the user's choosing.

Any help would be greatly appreciated, it is exceedingly frustrating to
have an automation that takes hours to setup to basically die because of a
network hiccup, and we are in dire need of a more robust mechanism for
communication.

Thanks much,

Ed