
https://mosh.mit.edu/ If you scroll down, there's an introductory video that's pretty interesting. Sounds like a great idea, with a couple caveats: I wonder about the security and there's a wicked hook in a question right at the end that suggests it's very NOT firewall friendly. Packages are available for Debian, and apparently other distros too. Anyone tried it, or using it on a regular basis? -- Giles http://www.gilesorr.com/ gilesorr@gmail.com

What about ssh and screen? If your ssh session goes away the screen session will stay in place till you reconnect. I bet with a little ~/.profile work you could get all the reconnect and setup stuff to happen auto-magically On 12/01/2015 02:26 PM, Giles Orr wrote:
If you scroll down, there's an introductory video that's pretty interesting. Sounds like a great idea, with a couple caveats: I wonder about the security and there's a wicked hook in a question right at the end that suggests it's very NOT firewall friendly.
Packages are available for Debian, and apparently other distros too.
Anyone tried it, or using it on a regular basis?
-- Alvin Starr || voice: (905)513-7688 Netvel Inc. || Cell: (416)806-0133 alvin@netvel.net ||

On 1 December 2015 at 14:26, Giles Orr <gilesorr@gmail.com> wrote:
If you scroll down, there's an introductory video that's pretty interesting. Sounds like a great idea, with a couple caveats: I wonder about the security and there's a wicked hook in a question right at the end that suggests it's very NOT firewall friendly.
Packages are available for Debian, and apparently other distros too.
Anyone tried it, or using it on a regular basis?
I use it quite a lot on my "wandery laptop." It's very nice to be able to just not worry about session survival most of the time. (I'm *well* aware of Screen/tmux as a different model on that...) The thing I find mighty likable is that unlike the other mechanisms. it is consciously lossy about traffic. That is, it tracks the state of the screen, and happily throws away past updates that took place while you've been gone. That's a nice feature when running "top" in a window; if you ssh'ed in, and have a network glitch for a few seconds, the ssh session is then busy for seconds (or more...) drawing all of the screen updates that happened while you weren't properly connected. With Mosh, it ignores those interim changes, and updates to the latest state of the terminal session. That also means that if you are running a more/less session (on, say, logs), and hit "space" a few times, you will find it scrolls MUCH more quickly than an ssh session would, as the page-forward requests get across and invalidate some interim screens of data. Running that across ssh, you'd find that the session plays *all* the data. Security shouldn't be *too* bad; it uses the usual (ssh-based and doubtless TCP) mechanisms to negotiate the initial connection, then uses UDP to update state after that. They do describe security somewhat: ------------------------------------------------- Q: How does Mosh's security compare with SSH's? We think that Mosh's conservative design means that its attack surface compares favorably with more-complicated systems like OpenSSL and OpenSSH. Mosh's track record has so far borne this out. Ultimately, however, only time will tell when the first serious security vulnerability is discovered in Mosh—either because it was there all along or because it was added inadvertently in development. OpenSSH and OpenSSL have had more vulnerabilities, but they have also been released longer and are more prevalent. In one concrete respect, the Mosh protocol is more secure than SSH's: SSH relies on unauthenticated TCP to carry the contents of the secure stream. That means that an attacker can end an SSH connection with a single phony "RST" segment. By contrast, Mosh applies its security at a different layer (authenticating every datagram), so an attacker cannot end a Mosh session unless the attacker can continuously prevent packets from reaching the other side. A transient attacker can cause only a transient user-visible outage; once the attacker goes away, Mosh will resume the session. However, in typical usage, Mosh relies on SSH to exchange keys at the beginning of a session, so Mosh will inherit the weaknesses of SSH—at least insofar as they affect the brief SSH session that is used to set up a long-running Mosh session. ------------------------------------------------- -- When confronted by a difficult problem, solve it by reducing it to the question, "How would the Lone Ranger handle this?"

On Tue, Dec 01, 2015 at 02:26:24PM -0500, Giles Orr wrote:
If you scroll down, there's an introductory video that's pretty interesting. Sounds like a great idea, with a couple caveats: I wonder about the security and there's a wicked hook in a question right at the end that suggests it's very NOT firewall friendly.
Packages are available for Debian, and apparently other distros too.
Anyone tried it, or using it on a regular basis?
I looked at it, but the restrictions make it unusable in my opinion. https://en.wikipedia.org/wiki/Mosh_%28software%29#Prerequisites_to_the_serve... Having to allow arbitrary UDP to my servers it just not practical. I find ssh in general reliable enough that the occational need to reconnect and reattach to screen is no big deal, and certainly not worth the cost needed to run mosh. -- Len Sorensen
participants (4)
-
Alvin Starr
-
Christopher Browne
-
Giles Orr
-
Lennart Sorensen