openssh unix dev - Oct 2012 - ssh over udp (or: -L option listening for traffic with a UDP service?)

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

Edward Peschko wrote:
> 2. Has anybody done it?
openvpn implements a UDP transport which is very reliable.

> 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.
How would that help? Your problem seems to be to get SSH working at
all. Since that doesn't work I guess it's difficult to use anything
that exists *on top of* SSH?


//Peter

ssh has support for ProxyCommand, which allows you to swap out the underlying
TCP transport for "something else" (in my case, DNS).

There used to be a really nice tool for reliable UDP comms over GPRS, but I
can't find it. Probably something could be build with UDT or ENET...

Sent from my iPhone

On Oct 10, 2012, at 1:22 PM, Edward Peschko <ed.peschko at gmail.com>
wrote:
> 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
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev