TCP mode?

[keithw]

Allow degenerate use of TCP and HTTP CONNECT modes for people who can't use UDP.

[jhnlsn]

I would also like to see something like this as well. UDP has been disable on our network.

[sourcefrog]

I wonder if you could in fact just run mosh's delta-updating protocol over the ssh channel, which will be even more likely to just fit in with people's firewalls, and still possibly faster than plain ssh. Maybe it's a separate issue.

[andreasvc]

sourcefrog's idea is better, SSH is already required so using that connection reduces firewall issues to zero. It would be neat if UDP connectivity would be autodetected with fallback to SSH.

[saurik]

@andreasvc The problem with using the SSH connection is that once it dies, in order to reestablish it, you will need to re-authenticate with the server using the SSH authentication mechanisms. At that point, you honestly are going to get most of the remaining benefits of mosh by just using autossh (an old and venerable project that has been maintained over many years) and attaching to a remote screen/tmux session.

To do this, you can use a command like the one below. The main problem with it is that autossh has an irritating timing fallback algorithm when it fails; so, you open your laptop, it starts trying to reconnect, and the attempts get slower and slower before your networking even comes online, and so sometimes you have to wait 10-30 seconds after your Internet kicks back in before it reconnects. Fixing that, however, is obviously a trivial patch.

function cysh() {
    AUTOSSH_GATETIME=0 autossh -M 0 -t -e none \
        -o ServerAliveInterval=2 -o ServerAliveCountMax=4 \
        $1 screen -dr $2
}

[andreasvc]

@saurik: I don't know about "most". I think the predictive echo of mosh is the most important benefit, which compensates for latency. So I think mosh-over-ssh would be useful.

[saurik]

@andreasvc That ability is totally independent of networking: simply mosh to localhost and your terminal will have type-ahead prediction on it; it is the ability to drop intermediate results that makes that something to tie together with a networking layer (otherwise mosh could simply be a patch to tmux or screen that smooths the latency of any application run underneath it, remote or local).

[andreasvc]

OK predictive echo was the wrong example; but what about sourcefrog's suggestion, to "run mosh's delta-updating protocol over the ssh channel", isn't that possible? If not, why? I understand that UDP has advantages, but maintaining state on both ends makes for a more efficient protocol with TCP/SSH as well, I think. Such a watered-down mosh version would be very useful with firewalls that only allow TCP port 22, and by ensuring mosh works wherever ssh works it becomes a drop-in replacement.

[keithw]

@saurik Well, not exactly -- the early versions of mosh did have client-only local echo as you describe. But unfortunately we need a (a) fast and (b) accurate way to detect false-positive and true-positive predictions, and so we ended up needing to do the current server-side "echo ack" mechanism to have a smooth experience, because of network jitter and other reasons. So mosh to localhost and then ssh remotehost will produce glitches you won't see with mosh remotehost.

[keithw]

My current thinking of how we will do mosh-over-ssh (possibly -over-HTTP-proxy) is that we will just run a local proxy that will take UDP packets (or Unix domain datagrams) and pipe them over SSH and turn them into UDP (or Unix domain datagrams) on the server side. That way we can just treat the whole SSH connection like an EV-DO link or any other link that might have varying RTT, and get most of the benefits of the mosh timing and varying frame rate.

[saurik]

@keithw I am quite interested in that; I would have expected there to be know way to tell the difference between those two environments. If I type a character into mosh-client, it is sent to a remote system and received by mosh-server, mosh-server will then place it into the pseudo-terminal to be read by the running shell. At some point later it will be echoed back to the terminal, and will appear to mosh-server. In comparison, were I to type it into mosh-client to be sent to a local copy of mosh-server, and it to then be placed into the pseudo-terminal and read by ssh, sent over the network to another machine, copied into that pseudo-terminal and then later echoed back, read to copy over ssh, and then finally displayed through to mosh-server, is not not accurate to claim that all of those later steps are simply encapsulated in the running shell? Put differently, how is being connected to a running copy of ssh different than being connected to a running copy of screen or even vim? Does mosh rely on some kind of expected delay-to-echo? Would I run into the same problem with a very slow process, or mosh to a remote server followed by ssh to yet a different server?

[saurik]

@andreasvc I explained in my earlier comment to you that "the problem with using the SSH connection is that once it dies, in order to reestablish it, you will need to re-authenticate with the server using the SSH authentication mechanisms". To make this more clear: if you use the autossh mechanism I described (which is clunky as hell), you will notice that every time it reconnects you need to re-authenticate; this may be reasonable using a private key, but only if that private key does not have a passphrase on it; if you have a passphrase on your key (a good idea, although on OS X the keychain mechanism for handling that is pretty cool) or use password authentication the experience becomes really irritating as you reconnect (especially so as you may be typing along and suddenly be given a password prompt), and with challenge-response authentication it becomes utter torture as you reach for your hardware token.

[saurik]

@keithw I was actually discussing the "tunnel UDP over SSH" option with someone last night, but given that you will still need to have a mechanism to maintain the active SSH channel (such as autossh) it almost makes sense to relegate that to its own general-purpose project that manages arbitrary UDP channels over arbitrary TCP channels: it could then be layered over an underlying SSH port forwarding, but would be free to be used in other contexts as well.

[andreasvc]

Reconnecting SSH is painless if you use a private key with an ssh-agent (contrary to what you say, it does not have to be passwordless); I assume the OS X keychain is similar to what Gnome/KDE provides: one password prompt which is remembered as long as the ssh-agent runs. Even if you don't use private keys, the mosh client could remember the password so you don't have to retype it. So I don't see SSH re-authentication as a problem. On the contrary, running everything over SSH will appease the skeptics who say that mosh does not have a proven security record.

I think sending the UDP packets over SSH directly, as Keith seems to suggest, is faster than using a TCP connection within SSH. When I ssh to another host within an ssh session, it is reasonably fast; however, if I add a port forward to that same ssh server and connect to that, I get noticeable latency.

[saurik]

@andreasvc Fair enough: I thought that ssh-agent only was related to forwarding passkeys to remote hosts. I will learn more about ssh-agent so I do not make similar mistakes in the future (and it may also help some of my use cases). Sorry, and thanks!