Mosh: the mobile shell(mosh.mit.edu)
mosh.mit.edu
Mosh: the mobile shell
http://mosh.mit.edu/#about
23 comments
I was sad because it was disturbed when I try to login my VPS(Burst) from mainland China with Mosh, after I was so happy to find it and installed it on all my Linux OS.
Previous discussion
http://news.ycombinator.com/item?id=3819382
Relevant discussion from an hour ago: http://news.ycombinator.com/item?id=5016357
I would love to use it but last time this came up (almost a year ago), people voiced security concerns.
Any different perspectives on this now?
Any different perspectives on this now?
One of them, besides the elite crypto issues, is that mosh requires having a wide range of UDP ports open to function properly. Many admins are not willing to do that.
You can pick a single UDP port and use `mosh -p`.
Absent a single privileged moshd, though, every user's mosh-server process needs to have its own UDP port, hence the default behavior. If you want to assign yourself a UDP port and open that single port on the firewall, you can, though.
Absent a single privileged moshd, though, every user's mosh-server process needs to have its own UDP port, hence the default behavior. If you want to assign yourself a UDP port and open that single port on the firewall, you can, though.
which is exactly the issue.
Well, it's been a while with no security issues, hasn't it? That's mostly how software ends up being considered secure.
No, I think having a high quality secure design and a security audit by examining code is how software is considered secure. OpenBSD audits every line of code that it ships, and the last remote root exploit I could find was 2007. DJB's stuff (qmail, djbdns) are designed to be secure from the ground up, and I believe are considered to be secure. (Opinions vary about other aspects of his stuff, though.) "It's been a while since I heard of a virus on Mac OS" is how Mac OS is often considered secure, yet the list of remote exploits is rather large [2], compared to OpenBSD's (exploit-db.com doesn't even know of the 2007 one, but Mac OS has more remote exploits than OpenBSD has local explots [3]!)
[1] http://www.coresecurity.com/content/open-bsd-advisorie [2] http://www.exploit-db.com/remote/?p=osX [3] http://www.exploit-db.com/platform/?p=openbsd
[1] http://www.coresecurity.com/content/open-bsd-advisorie [2] http://www.exploit-db.com/remote/?p=osX [3] http://www.exploit-db.com/platform/?p=openbsd
Have you actually seen the OSX exploits listed? It's to do with .exe binaries or Internet Explorer that has nothing to do with OSX.
In part, this is why I've submitted this again. There have been previous discussions, but comments there are closed, and many people aren't aware of it, so I thought it was a good opportunity to allow those "in the know" to tell us if anything has changed, and if it's fit for purpose.
I love mosh, I've been using it since it was released and it's been working flawlessly.
While a nice idea, licensing issues are a problem for this project... I don't understand why they didn't use the standard MIT license, but instead went for GPL3, but still chose a proprietary encryption method.
iSSH on iOS now also experimentally supports it with an own independent implementation, with an in-app purchase, since the encryption uses a proprietary encryption method only freely licensed for opensource projects.
iSSH on iOS now also experimentally supports it with an own independent implementation, with an in-app purchase, since the encryption uses a proprietary encryption method only freely licensed for opensource projects.
OCB has a clean, short, embeddable reference implemention, and there's a patent grant permitting usage in GPL projects. (Calling it "proprietary" is a stretch, but I understand what you mean.)
GCM didn't have any great implementations. There's starting to be an implementation in OpenSSL 1.0, but at the time mosh was written, that was difficult to count on, and even now that's still shaky.
It's important that the crypto algorithm implementation be known to be correct and safe (avoid side channels, etc.).
As far as I know there's no particular reason that iSSH does not use the standard mosh implementation. One thing to note is that iSSH is not free software (everything it embeds -- PuTTY, Xorg, dwm, etc. -- is under an MIT-style license), so embedding a GPL project would have forced them to open up the iSSH source code.
It would be great if someone wanted to write a free software terminal emulator for iOS, and at that point you can absolutely include mosh. (I'd probably encourage _building_ on mosh, which happens to include a rigorous terminal implementation.) But it's true that you can't embed GPL software inside proprietary software.
GCM didn't have any great implementations. There's starting to be an implementation in OpenSSL 1.0, but at the time mosh was written, that was difficult to count on, and even now that's still shaky.
It's important that the crypto algorithm implementation be known to be correct and safe (avoid side channels, etc.).
As far as I know there's no particular reason that iSSH does not use the standard mosh implementation. One thing to note is that iSSH is not free software (everything it embeds -- PuTTY, Xorg, dwm, etc. -- is under an MIT-style license), so embedding a GPL project would have forced them to open up the iSSH source code.
It would be great if someone wanted to write a free software terminal emulator for iOS, and at that point you can absolutely include mosh. (I'd probably encourage _building_ on mosh, which happens to include a rigorous terminal implementation.) But it's true that you can't embed GPL software inside proprietary software.
I was under the impression that you can't include GPL stuff in App Store apps full stop.
I definitely get the concern over proprietary encryption, but why does the license matter for an end user like me?
Because due to the license the code can not be included on certain platforms or in applications which is preventing wider adoption.
Are there particular platforms you're thinking of? The big complaint was iOS, which was resolved a while ago. (The legal constraints around the app store are complicated, but basically, Apple does not reject GPL apps. So it merely requires the copyright holders to agree that distribution on the App Store does not infringe their rights under the GPL, which is a reasonable position to take.)
Well Panic said they wouldn't be including mosh support into Prompt, their iOS app due to the license.
So there is that.
So there is that.
That seems to be at odds with this other comment in the thread:
http://news.ycombinator.com/item?id=5017160
Was this statement before the mosh repo gained the COPYING.iOS file and the iOS-related waiver from the OCB patent holder (July 20, 2012)?
Was this statement before the mosh repo gained the COPYING.iOS file and the iOS-related waiver from the OCB patent holder (July 20, 2012)?
From April of this year at least, i'll have to dig up the tweet.
edit: was this tweet http://twitter.com/panic/status/195938318536544257
edit: was this tweet http://twitter.com/panic/status/195938318536544257
For a library that is GPL, you would need that library's authors to relicense it to allow it on the App Store.
It's not that reasonable: the Apple EULA requires things that directly conflict with the GPL, such as the EULA requiring non-distribution of the binary.
It's not that reasonable: the Apple EULA requires things that directly conflict with the GPL, such as the EULA requiring non-distribution of the binary.
Take a look at this note:
https://github.com/keithw/mosh/blob/master/COPYING.iOS
https://github.com/keithw/mosh/blob/master/COPYING.iOS
Many paranoid companies will often prohibit all use of GPLv3 software. The justification I've heard is that the terms of the license make it possible that anything you produce using GPLv3 software is also GPLv3. So, for example, if you use a GPLv3 licensed version of emacs, and you write some code, the code you wrote will also become GPLv3. It's a very conservative reading of the terms of the license, but understandable for companies which have most of their net worth tied up in source code.
I forgot to point out while the discussion was still active that "proprietary encryption" is a bit of a misnomer. 90% of people who use that phrase mean "we use a super-secret algorithm and if we tell you how the algorithm works the bad guys will break it", aka, a weak and unaudited security-by-obscurity algorithm.
OCB is no more proprietary than RSA was when it was still under patent protection (throughout the '90s, I believe), the reference implementation is public, and Mosh incorporates the reference implementation into its GPL source. The algorithm is well-documented in the research literature, and the implementation is available under a free software (though strong copyleft) license.
OCB is no more proprietary than RSA was when it was still under patent protection (throughout the '90s, I believe), the reference implementation is public, and Mosh incorporates the reference implementation into its GPL source. The algorithm is well-documented in the research literature, and the implementation is available under a free software (though strong copyleft) license.
Because depending on the policies of your workplace, GPLv3 may be blacklisted; the nature of that license makes its use in certain classes of business very, very dangerous.
> the nature of that license makes its use in certain classes of business very, very dangerous
Well, thats the point of it.
Well, thats the point of it.
Many paranoid companies will often prohibit all use of GPLv3 software. The justification I've heard is that the terms of the license make it possible that anything you produce using GPLv3 software is also GPLv3. So, for example, if you use a GPLv3 licensed version of emacs, and you write some code, the code you wrote will also become GPLv3. It's a very conservative reading of the terms of the license, but understandable for companies which have most of their net worth tied up in source code.
> The terms of the licence make it possible....
No, they do not. In fact, the example you gave is exactly the example given by the FSF to explain why this does not occur.
http://www.gnu.org/licenses/gpl-faq.html#CanIUseGPLToolsForN...
It's not a conservative reading so much as an incorrect one, and it's also nothing to do with v3 versus v2. The concern about v3 is that it means that companies are not allowed to use patent or hardware restrictions to do an end-run around the GPL's user protections.
The "viral contamination" FUD has been around for over a decade at least; it's nothing to do with version 3.
No, they do not. In fact, the example you gave is exactly the example given by the FSF to explain why this does not occur.
http://www.gnu.org/licenses/gpl-faq.html#CanIUseGPLToolsForN...
It's not a conservative reading so much as an incorrect one, and it's also nothing to do with v3 versus v2. The concern about v3 is that it means that companies are not allowed to use patent or hardware restrictions to do an end-run around the GPL's user protections.
The "viral contamination" FUD has been around for over a decade at least; it's nothing to do with version 3.
This shows a bit of a misunderstanding of how copyright law works. Just because a tool was used in creating a work does not mean that the created work is a derivative, unless the work somehow incorporates the tool.
[deleted]
http://www.zinger-soft.com/iSSH_features.html
iSSH includes the mosh protocol as a 99c in-app purchase. Use mosh on your mobile device, just where it should be!
iSSH includes the mosh protocol as a 99c in-app purchase. Use mosh on your mobile device, just where it should be!
Mosh has been brilliant so far. I travel a lot by train but even SSH'ing over the trains WiFi can be problematic. Connecting through Mosh solves all the typical issues and with local echo you can continue to type as if the connection was still up.
I just installed this on my Chromebook with Ubuntu, and on my EC2 instance. I've been very frustrated with the lag I was experiencing while typing in the shell, due to high/variable latency. In my very preliminary testing over the last hour, this has solved my problems almost completely.
Security is less of a concern because I'm running OpenVPN to my instances, so the UDP traffic mosh uses is encrypted anyway, and not open to the public.
One issue I did notice is that irssi isn't refreshing quite as quickly. Seems to lag behind the conversation a bit. I'll have to troubleshoot. I wonder if running byobu/screen is part of the problem.
Security is less of a concern because I'm running OpenVPN to my instances, so the UDP traffic mosh uses is encrypted anyway, and not open to the public.
One issue I did notice is that irssi isn't refreshing quite as quickly. Seems to lag behind the conversation a bit. I'll have to troubleshoot. I wonder if running byobu/screen is part of the problem.
I also run a similar setup and am trying out mosh now. I agree re: the lag in irssi. Additionally, if I start typing into irssi and then rapidly delete the text, I can delete the channel name temporarily:
[#startups] I was thiknin^H^H^H^H^H^H
[#startYeah, this is due to their clever predictive local echo not being that clever all the time. When the client sees that sending ^H actually results in character disappearing, it imitates that behaviour locally for next ^H:s making you experience less lag. Most of the time it works well but there's these edge cases with funny results.
Well, my simple solution would be to delete the channel name from the prompt because it does not serve me any purpose. Too bad I don't actually know how to do this in irssi, I already looked for an option.
You can use "/statusbar prompt disable" (and "/save" to make it persistent).
I simply could not work without mosh. I do not experience significant lag and it allows me to have connections open even if I switch from WiFi over to 3G and back which is often the case.
Are there any versions of this that work with Windows GUI apps? (Along the lines of puTTY instead of Cygwin)?
So, er, does the [mo]bile[sh]ell have a mobile app for iPhone?
iSSH has an independent proprietary implementation of the mosh protocol as an in-app purchase. (mosh itself has license terms explicitly permitting redistribution on the App Store, but nobody has done the port yet.)
Panic has mentioned that they will fully implement Mosh into their Prompt iOS client, it's just not high priority at the moment.
http://twitter.com/panic/status/281208183094145024
http://twitter.com/panic/status/281208183094145024
By the way, with mosh we can have persistent shell over changing IP address, is there a text editor that would work with SFTP in a similar persistent way?
I mean, suppose I work on a project, close the laptop lid and some time later, open it. I might have a new IP, or in general the SSH connection might have been terminated.
In that case I would have to reload all the files in the project. Would it be possible to do IP hopping and maintain the SFTP connection unterminated?
I use Mac OS.
I mean, suppose I work on a project, close the laptop lid and some time later, open it. I might have a new IP, or in general the SSH connection might have been terminated.
In that case I would have to reload all the files in the project. Would it be possible to do IP hopping and maintain the SFTP connection unterminated?
I use Mac OS.
There's a ticket (with no discussion) about a mosh equivalent for SFTP/sshfs:
https://github.com/keithw/mosh/issues/280
yeah, seems pointless without an iOS implementation. (pointless for people on mobile Apple products that is (iPhone, iPad, iPod touch))
If anyone is interested in the downsides:
1) mosh lowers the average latency, but it causes the perceived latency to be highly variable.
The issue is that there are various moments where the algorithm somewhat-correctly decides it cannot predict what will happen due to new incoming keystrokes. An example of this is after you hit enter: you might be running an entirely different program at this point.
In essence, the algorithm "warms up" as it makes correct decisions, and once it decides "ok, my decisions seem accurate: when he types a character they seem to echo back to the terminal" it makes a sudden transition from "slightly slower than raw SSH" to "much faster than SSH and only slightly slower than a local screen session".
These sudden transitions are jarring: when they happen to you with normal connections the expectation is "oh, my connection is failing", a feeling that with mosh you have every time you type a command.
Meanwhile, for the interactive-shell or complex-text-editor use case, these "unpredictable events" always happen at the worst possible moment: when you first start doing something; the result is that the perceived incidence of latency is actually worse than with normal SSH, as every "new event" has a higher latency... by the time it starts prediction, you are probably "in the flow" enough to not even be paying attention.
2) it relies on a specific range of UDP ports
Because it operates over a custom supposedly-mobile-optimized protocol, it tends to end up being inaccessible when you actually need it due to pervasive modern firewalls. You'll start a session at home, go to the office, and... nothing... because you can't communicate over that UDP port. This happened to me quite often while evaluating mosh.
3) it doesn't have a good way to reconnect later
While it supports sitting down at a different computer and taking over your session, it requires you to drop to a rather low-level mechanism based on knowing the secret session key that was established at the time the server was setup. This actually undermines the "mobile" use case, as it only lets the connection be mobile, not the session.
(I also have some specific issues with a library it relies on for spoofing hostnames in wtmp: just having that library installed on your system opens a vulnerability where any non-privileged user can spoof their hostname as anyone else... their opinion differs, but it seems to mostly be due to a knee-jerk reaction of "you don't get fired for avoiding setuid" than "this is actually secure".)
The result is that after spending a bunch of time testing it, working with the codebase, getting frustrated at a bunch of the design decisions, and then having it both totally fail to work in real-world network settings and become yet another source of infuriating latency, I pretty much dropped all interest in the project and replaced it with autossh, which worked great.
However: it doesn't require any special code on the server, which is a downside of mosh I didn't even list above (as it is fairly obvious and something you know going in): this means you get to use it for every connection to every server you might ever care about.
Otherwise, you get everything you expect from normal ssh and screen: it works everywhere you might theoretically have been able to connect to the server anyway (so no ending up at the client site and finding out that they firewall UDP), it is obvious how to reconnect to (or even share) the screen session from a different computer or a different client without special software, and you don't need to even contemplate "what if this introduces a security vulnerability by running a new daemon on my server?".
The other annoyance of using autossh is it is pretty adamant about doing exponential back-off on reconnect, and in the naive way I have it setup in that function it is also going to be doing slow-to-fail DNS requests as it attempts to do the reconnection sequence, so the result is that the "open laptop, wait for all terminals to connect" sequence doesn't always click perfectly.
However, that is easily fixable by using a simpler wrapper (to be clear: use autossh when autossh is appropriate; it is designed, however, for server-to-server backend links to maintain persistent port forwarding), so I bring you cysh.sh, which is what I actually use (and which I've done some testing with others to verify works on random platforms):
http://test.saurik.com/hackernews/cysh.sh
(Yes: you are now downloading a random shell script from someone on a web forum. However, it's like 35 lines of very easily readable sh: you should just read it; hell, after reading it, you might consider it so simple you just want to rewrite it for yourself. ;P)
You use this in the same way as the function, which I didn't even document earlier anyway as I knew I'd just be replacing it with this shell script by the end of the comment ;P.
(BTW, if you are curious why I have it set to do -dRS "by default" as opposed to -xRS, is that if you have multiple clients associated with the session the size of window can't be automatically updated; the result is that you often find yourself connecting back to copies of things like irssi or even bash prompts that are now the wrong width; -dRS works perfectly out of the box. Many people, however, know enough about screen that they love -x: if that includes you, you should definitely just change that.)
So, if you don't need the "severe packet loss" protection, I really think you are better off just passing on mosh and using something infinitely simpler cobbled over ssh. The latency mitigation feature are overrated or even annoying, and it seems many people actually just want mosh for "easily auto-reconnecting mobile shell", something you seriously can solve very well with a very short shell script and no special server-side logic.
(If anyone tries using that script, it doesn't work, and you want help debugging it, I'm happy to do so; that said, it is purposely not "a product" right now because different people seem to want different things, and it is frankly really simple to write this from scratch if you need it, or just kind of pull it apart and fix/change whatever you don't like about it: just attempting to get an automatically-reconnecting shell is a fairly simple problem.)
1) mosh lowers the average latency, but it causes the perceived latency to be highly variable.
The issue is that there are various moments where the algorithm somewhat-correctly decides it cannot predict what will happen due to new incoming keystrokes. An example of this is after you hit enter: you might be running an entirely different program at this point.
In essence, the algorithm "warms up" as it makes correct decisions, and once it decides "ok, my decisions seem accurate: when he types a character they seem to echo back to the terminal" it makes a sudden transition from "slightly slower than raw SSH" to "much faster than SSH and only slightly slower than a local screen session".
These sudden transitions are jarring: when they happen to you with normal connections the expectation is "oh, my connection is failing", a feeling that with mosh you have every time you type a command.
Meanwhile, for the interactive-shell or complex-text-editor use case, these "unpredictable events" always happen at the worst possible moment: when you first start doing something; the result is that the perceived incidence of latency is actually worse than with normal SSH, as every "new event" has a higher latency... by the time it starts prediction, you are probably "in the flow" enough to not even be paying attention.
2) it relies on a specific range of UDP ports
Because it operates over a custom supposedly-mobile-optimized protocol, it tends to end up being inaccessible when you actually need it due to pervasive modern firewalls. You'll start a session at home, go to the office, and... nothing... because you can't communicate over that UDP port. This happened to me quite often while evaluating mosh.
3) it doesn't have a good way to reconnect later
While it supports sitting down at a different computer and taking over your session, it requires you to drop to a rather low-level mechanism based on knowing the secret session key that was established at the time the server was setup. This actually undermines the "mobile" use case, as it only lets the connection be mobile, not the session.
(I also have some specific issues with a library it relies on for spoofing hostnames in wtmp: just having that library installed on your system opens a vulnerability where any non-privileged user can spoof their hostname as anyone else... their opinion differs, but it seems to mostly be due to a knee-jerk reaction of "you don't get fired for avoiding setuid" than "this is actually secure".)
The result is that after spending a bunch of time testing it, working with the codebase, getting frustrated at a bunch of the design decisions, and then having it both totally fail to work in real-world network settings and become yet another source of infuriating latency, I pretty much dropped all interest in the project and replaced it with autossh, which worked great.
function cysh() {
AUTOSSH_GATETIME=0 autossh -M 0 -t -e none \
-o ServerAliveInterval=2 -o ServerAliveCountMax=4 \
"$1" screen -xRS "$2"
}
However: it doesn't require any special code on the server, which is a downside of mosh I didn't even list above (as it is fairly obvious and something you know going in): this means you get to use it for every connection to every server you might ever care about.
Otherwise, you get everything you expect from normal ssh and screen: it works everywhere you might theoretically have been able to connect to the server anyway (so no ending up at the client site and finding out that they firewall UDP), it is obvious how to reconnect to (or even share) the screen session from a different computer or a different client without special software, and you don't need to even contemplate "what if this introduces a security vulnerability by running a new daemon on my server?".
The other annoyance of using autossh is it is pretty adamant about doing exponential back-off on reconnect, and in the naive way I have it setup in that function it is also going to be doing slow-to-fail DNS requests as it attempts to do the reconnection sequence, so the result is that the "open laptop, wait for all terminals to connect" sequence doesn't always click perfectly.
However, that is easily fixable by using a simpler wrapper (to be clear: use autossh when autossh is appropriate; it is designed, however, for server-to-server backend links to maintain persistent port forwarding), so I bring you cysh.sh, which is what I actually use (and which I've done some testing with others to verify works on random platforms):
http://test.saurik.com/hackernews/cysh.sh
(Yes: you are now downloading a random shell script from someone on a web forum. However, it's like 35 lines of very easily readable sh: you should just read it; hell, after reading it, you might consider it so simple you just want to rewrite it for yourself. ;P)
You use this in the same way as the function, which I didn't even document earlier anyway as I knew I'd just be replacing it with this shell script by the end of the comment ;P.
cysh [email protected] stuff
(BTW, if you are curious why I have it set to do -dRS "by default" as opposed to -xRS, is that if you have multiple clients associated with the session the size of window can't be automatically updated; the result is that you often find yourself connecting back to copies of things like irssi or even bash prompts that are now the wrong width; -dRS works perfectly out of the box. Many people, however, know enough about screen that they love -x: if that includes you, you should definitely just change that.)
So, if you don't need the "severe packet loss" protection, I really think you are better off just passing on mosh and using something infinitely simpler cobbled over ssh. The latency mitigation feature are overrated or even annoying, and it seems many people actually just want mosh for "easily auto-reconnecting mobile shell", something you seriously can solve very well with a very short shell script and no special server-side logic.
(If anyone tries using that script, it doesn't work, and you want help debugging it, I'm happy to do so; that said, it is purposely not "a product" right now because different people seem to want different things, and it is frankly really simple to write this from scratch if you need it, or just kind of pull it apart and fix/change whatever you don't like about it: just attempting to get an automatically-reconnecting shell is a fairly simple problem.)
If you're willing to sell "just use screen" as an answer for auto-reconnecting, why not "just use screen" with mosh? That's what I do, and I don't have any trouble with point 3 -- I just open a new mosh connection, and reattach my existing screen session.
(Points 1 and 2, for what they're worth, seem pretty specific to your environment. I've never run into them. So, please bill those as anecdotes.)
(Points 1 and 2, for what they're worth, seem pretty specific to your environment. I've never run into them. So, please bill those as anecdotes.)
One reason is that mosh adds a bunch of latency itself that is at least comparable to (and frankly somewhat heavier than) screen (if you don't believe me, I can find a quote from the primary author), a latency which is itself somewhat noticeable: once you layer screen into mosh, the situation tends to get sufficiently unreasonable that even on perfect connections the jarring latency effect becomes worse (as when a mis-predict occurs you are now going through two layers: mosh and screen; of course for the prediction case, you are still just dealing with the one layer).
(Then, once you are using screen to solve problem #3, my argument is then that unless you need the features from mosh that deal with packet loss, you can start attempting to whittle away at any other things that may have been less-than-perfect regarding mosh, as you might simply not need it anymore.)
As for your contention that #1 and #2 are "anecdotes", it isn't like I'm just saying "engh, didn't work": I'm explaining exactly why these things are issues from first principals so you can evaluate whether they will effect you or not: it isn't like whether mosh requires weird UDP ports is somehow subjective.
I mean, let's say I had said "one downside of deploying a mobile application instead of a website is that if a user doesn't have a smartphone your content might be inaccessible to them"... is that an "anecdote"? Maybe all your customers have smartphones, and if so you can ignore that, but at least you are aware of it.
(BTW, if you want another example of where the prediction goes insane: if you mosh to a server and then SSH from that server to another server, the latency between mosh and the remote client can no longer be measured by the protocol, and the prediction system gets very confused and mostly ends up turning off. I had a long conversation with the mosh developer about this issue when it affected me. However, that's even rarer for people to run into.)
(Then, once you are using screen to solve problem #3, my argument is then that unless you need the features from mosh that deal with packet loss, you can start attempting to whittle away at any other things that may have been less-than-perfect regarding mosh, as you might simply not need it anymore.)
As for your contention that #1 and #2 are "anecdotes", it isn't like I'm just saying "engh, didn't work": I'm explaining exactly why these things are issues from first principals so you can evaluate whether they will effect you or not: it isn't like whether mosh requires weird UDP ports is somehow subjective.
I mean, let's say I had said "one downside of deploying a mobile application instead of a website is that if a user doesn't have a smartphone your content might be inaccessible to them"... is that an "anecdote"? Maybe all your customers have smartphones, and if so you can ignore that, but at least you are aware of it.
(BTW, if you want another example of where the prediction goes insane: if you mosh to a server and then SSH from that server to another server, the latency between mosh and the remote client can no longer be measured by the protocol, and the prediction system gets very confused and mostly ends up turning off. I had a long conversation with the mosh developer about this issue when it affected me. However, that's even rarer for people to run into.)
I'm not sure I've ever seen screen add latency.
(And yes, I do regularly use mosh to deal with packet loss over a 3G/4G connection; that's its primary value for me.)
"Pervasive modern firewalls" is an anecdote. Even at cafes and such, mosh works, anecdotally, for me.
(And yes, I do regularly use mosh to deal with packet loss over a 3G/4G connection; that's its primary value for me.)
"Pervasive modern firewalls" is an anecdote. Even at cafes and such, mosh works, anecdotally, for me.
I would consider you to be very lucky to have not run into a firewall that auto-blocks all UDP. Both my high school and my first employer blocked UDP altogether. (The former went as far as only white-listing outbound TCP connections on ports 21, 80, and 443, with ports on the latter two being transparently redirected through a very restrictive filter.)
Funny, my school's network is very restrictive about TCP (out of the ports I've tested only 80 and 443 have worked properly), but it doesn't do any deeper filtering, and has no restrictions at all for UDP.
> "Pervasive modern firewalls" is an anecdote. Even at cafes and such, mosh works, anecdotally, for me.
We have a firewall rule set up to allow inbound ssh on port 443 to one of our office servers because several of our clients have networks that are so locked down that whenever one of us needs to work from their offices from time to time, it's the easiest way of ensuring they'll have ssh access...
Cafe's are not a good example. Cafe-run public wifi tends to be some of the least secured internet access you can find.
We have a firewall rule set up to allow inbound ssh on port 443 to one of our office servers because several of our clients have networks that are so locked down that whenever one of us needs to work from their offices from time to time, it's the easiest way of ensuring they'll have ssh access...
Cafe's are not a good example. Cafe-run public wifi tends to be some of the least secured internet access you can find.
In theory, screen will absolutely add latency because it's another indirection terminal (your input has to traverse SSH, then SSH's terminal, then screen's terminal, then your process, then back). Again in theory, that addition should be fairly small on the surface.
In practice, and merely anecdotally on my part, I can attest that screen "feels" slower than a shell when I'm using it via SSH.
In practice, and merely anecdotally on my part, I can attest that screen "feels" slower than a shell when I'm using it via SSH.
Too bad Mosh cannot work with X display redirects. That one would have been rather handy.
The X protocol is not particularly well-designed for this. (The X protocol is not particularly well-designed for lots of things.)
One of mosh's advantages is that it does screen rendering on the server, and then synchronizes the screen with the client. So, if there's been ten screenfuls of outputs, and those packets were lost or delayed or the connection couldn't keep up, the client only needs to receive what's currently on the screen. (This doesn't work in the other direction, but there's typically a lot less traffic in that direction.)
You can't quite do that with X, since the X protocol itself involves no way to get / diff / synchronize the contents of the screen -- it involves a bunch of rendering operations, so if there's a delay, it needs to re-send those operations.
Still, there's an open ticket: https://github.com/keithw/mosh/issues/41
One of mosh's advantages is that it does screen rendering on the server, and then synchronizes the screen with the client. So, if there's been ten screenfuls of outputs, and those packets were lost or delayed or the connection couldn't keep up, the client only needs to receive what's currently on the screen. (This doesn't work in the other direction, but there's typically a lot less traffic in that direction.)
You can't quite do that with X, since the X protocol itself involves no way to get / diff / synchronize the contents of the screen -- it involves a bunch of rendering operations, so if there's a delay, it needs to re-send those operations.
Still, there's an open ticket: https://github.com/keithw/mosh/issues/41
Same here. I use tmux + mosh and I've been extremely happy with the results. I put my laptop to sleep, wake it back up and everything is right where I left it. If I need to use a different machine to connect I just take over the tmux session, and it doesn't really matter if I'm using mosh or ssh.
While I agree with all your points to some extent, and I don't actually like the way mosh has been made, I don't think your conclusion is fair.
When used on slow mobile networks, where I actually keep the same incoming IP (thus there is no reconnection), mosh works better than raw SSH for me and here's why:
- when switching cellphone towers, mosh's UDP catches up instantly. SSH's TCP waits for some retransmissions so that it knows if it's going to timeout or resume sending packets, and it takes _several_ seconds!
- prediction actually works well most of the time.
When used on slow mobile networks, where I actually keep the same incoming IP (thus there is no reconnection), mosh works better than raw SSH for me and here's why:
- when switching cellphone towers, mosh's UDP catches up instantly. SSH's TCP waits for some retransmissions so that it knows if it's going to timeout or resume sending packets, and it takes _several_ seconds!
- prediction actually works well most of the time.
I find switching cell phone towers to be something that happens sufficiently rarely that it doesn't matter if it skips for a second. I am willing to believe your mileage may vary. Really, if you are doing tons of work from cell phones, you may even prefer the mosh UDP protocol for its packet loss handling anyway: people should try it.
However, my experience has been that most of the people I have had go "omg, mosh sounds awesome!" are actually trying to use it from their laptop (not the phone) as they move from home to the office: mosh is not just overkill for that use case, it actually makes some "incorrect" tradeoffs. Maybe with an occasional "roaming on 3G" usage, but "from the coffee shop" not "in a train moving at 300km/h.
As for the mis-prediction issues, I guess we'll just have to differ on that one: if you like it, that's great, but the people I've talked to found the weird jerkiness that you get whenever you hit a prediction boundary awkward and jarring, especially as you end up with a boundary whenever you hit enter. I talked to the developer about the issue, and it didn't seem like something that could be worked around (semantically, I'm not even certain it is possible).
(They also may have fixed some of the more insane "visual artifacts" mosh was getting when I was using it: every time you'd hit enter in bash it would do this totally-wrong prediction of "take some characters and move them up a line, but not all of them". I thereby purposely didn't list it in my "downsides" list as the developer seemed to think that was fixable, unlike the mis-prediction boundary problem, but it certainly drove me crazy while using mosh.)
However, my experience has been that most of the people I have had go "omg, mosh sounds awesome!" are actually trying to use it from their laptop (not the phone) as they move from home to the office: mosh is not just overkill for that use case, it actually makes some "incorrect" tradeoffs. Maybe with an occasional "roaming on 3G" usage, but "from the coffee shop" not "in a train moving at 300km/h.
As for the mis-prediction issues, I guess we'll just have to differ on that one: if you like it, that's great, but the people I've talked to found the weird jerkiness that you get whenever you hit a prediction boundary awkward and jarring, especially as you end up with a boundary whenever you hit enter. I talked to the developer about the issue, and it didn't seem like something that could be worked around (semantically, I'm not even certain it is possible).
(They also may have fixed some of the more insane "visual artifacts" mosh was getting when I was using it: every time you'd hit enter in bash it would do this totally-wrong prediction of "take some characters and move them up a line, but not all of them". I thereby purposely didn't list it in my "downsides" list as the developer seemed to think that was fixable, unlike the mis-prediction boundary problem, but it certainly drove me crazy while using mosh.)
My number one use case is tethered mobile phone on a train. For everthing else I just use vanilla ssh and screen. You are right that if you just need mobility between office1, office2, coffeeshop, and home ssh with screen is probably all you really need.
I don't think mosh's developers really promote it as anything more than an experiment on improving shell connections on a high packet loss high latency mobile data plan.
I don't think mosh's developers really promote it as anything more than an experiment on improving shell connections on a high packet loss high latency mobile data plan.
I absolutely 100% agree with your final sentence: it isn't like I'm saying "the mosh people are perpetrating a plot to confuse people into doing this thing that is bad for them, a use case that no one in the world would ever have... (and trains are a communist plot: I doubt they exist)" ;P. In fact, I found the actual research paper that this was all for quite fascinating, and was glad to get a chance to talk directly to the author/developer about what he discovered.
I simply have been part of a ton of conversations about mosh, and I know that a lot of people who see mosh don't know what the design tradeoffs are towards the "high-latency w/ packet loss" use case were, and often are just looking for a tool that lets them move their shell around "between office1, office2, coffeeshop, and home".
ssh+screen by themselves simply is not a sufficient solution, as it doesn't automatically reconnect, so you either need to know how to setup autossh (which isn't marketed or optimized for this use case) or realize that the shell script isn't that difficult to build: I'm just trying to provide this information to people. At numerous points here I have been very clear: if you have interest in the features that you can only get from this integrated protocol setup, you should definitely try and possibly choose to use mosh.
I simply have been part of a ton of conversations about mosh, and I know that a lot of people who see mosh don't know what the design tradeoffs are towards the "high-latency w/ packet loss" use case were, and often are just looking for a tool that lets them move their shell around "between office1, office2, coffeeshop, and home".
ssh+screen by themselves simply is not a sufficient solution, as it doesn't automatically reconnect, so you either need to know how to setup autossh (which isn't marketed or optimized for this use case) or realize that the shell script isn't that difficult to build: I'm just trying to provide this information to people. At numerous points here I have been very clear: if you have interest in the features that you can only get from this integrated protocol setup, you should definitely try and possibly choose to use mosh.
I use mosh in the train = lot of cell tower switches.
I've very little use for it from the laptop on a "real" connection".
0) It sabotages your scrollback (just like screen), no more mouse-wheel scrolling. Showstopper for me.
Just in case you didn't know, you can access screens scrollback by hitting Control-a [ (exist with escape).
That's somewhat on purpose -- terminal rendering is on the server-side, so that if there's a lot of changes to the screen (a long terminal command, a full-screen curses app that did several updates, etc.), and the connection was bad during that, then the client only needs to see what's currently on the screen. If you're ever used a curses app over a bad connection, and seen it slowly update itself over the course of several seconds to catch up, you can understand why this is useful.
As other folks have mentioned, if you run screen on the server-side, then you can ask screen for its scrollback. Also, see this open ticket: https://github.com/keithw/mosh/issues/2
As other folks have mentioned, if you run screen on the server-side, then you can ask screen for its scrollback. Also, see this open ticket: https://github.com/keithw/mosh/issues/2
Yup I know the reasons and implications (have written my own terminal emulators in the past). I just felt the list is not complete without the biggest(?) annoyance of them all.
I wish someone would write a "dumb screen" that simply plays back the last n kb when I re-attach and otherwise doesn't try to emulate a terminal inside my terminal. screen and tmux (which I use heavily) are terrible crutches from a distant past that do way more (and poorly) than most people actually want.
I know mosh tries to fill a different niche (high latency links) so take this less as a stab against mosh but more as a general rant about the fact that it's 2013 and my laptop, which can render photo-realistic 3d videogames in realtime, is still not able to seamlessly resume a handful of text-mode terminal sessions without resorting to one of the above kludges.
Well, first world problems, shoemakers son always goes barefoot, etc...
I wish someone would write a "dumb screen" that simply plays back the last n kb when I re-attach and otherwise doesn't try to emulate a terminal inside my terminal. screen and tmux (which I use heavily) are terrible crutches from a distant past that do way more (and poorly) than most people actually want.
I know mosh tries to fill a different niche (high latency links) so take this less as a stab against mosh but more as a general rant about the fact that it's 2013 and my laptop, which can render photo-realistic 3d videogames in realtime, is still not able to seamlessly resume a handful of text-mode terminal sessions without resorting to one of the above kludges.
Well, first world problems, shoemakers son always goes barefoot, etc...
Screen doesn't 'sabotage' it. You're running a program called Screen. It has its own scrollback.
Even more: screen doesn't even always do that... I'm always in a screen, and if I scroll in iTerm2 (yes: using my trackpad as a mouse-wheel) it usually works the way I'd expect (I can naturally scroll back through the recent history of my shell session), and I can additionally scroll in screen (which will have weird ramifications, of course, on my local terminal scroll-back). (I have found this offers "best of both worlds", as I can get my recent scrollback locally and gracefully, but can dig through the history to get things I may have typed from different machines.)
Mess with the two checkboxes here: http://cl.ly/image/0K1A1w2m3X2c
Those are located in the Terminal tab of your Profile.
Also, go to the docs and see the following sections:
- Save lines to scrollback when an app status bar is present
- Disable save/restore alternate screen
Those contain the respective explanation for the two options.
http://www.iterm2.com/#/section/documentation/preferences
Those are located in the Terminal tab of your Profile.
Also, go to the docs and see the following sections:
- Save lines to scrollback when an app status bar is present
- Disable save/restore alternate screen
Those contain the respective explanation for the two options.
http://www.iterm2.com/#/section/documentation/preferences
I've spent the past year using Mosh from high latency, unreliable satellite connections in Afghanistan. I would have been pulling my hair out without it. My only complaint is the scrollback buffer often gets jumbled.
After using mosh on and off for a year, I realized that what they wrote in their PDF is absolutely true:
mosh latency isn't much different from SSH latency, which is a common misconception. What mosh adds is:
- decent prediction (this is what mitigate most of the latency)
- integrated auto-reconnect (even thus auto-ssh and others do the same thing, they're not built-in)
- mostly asynchronous keystrokes thanks to UDP+stream protocol, so if you hit ^C it will abort stuff even if the screen is scrolling. Note that the way keystrokes are handled makes it susceptible to a timing attack, and there might have been work to mitigate this that i'm unaware of.
mosh latency isn't much different from SSH latency, which is a common misconception. What mosh adds is:
- decent prediction (this is what mitigate most of the latency)
- integrated auto-reconnect (even thus auto-ssh and others do the same thing, they're not built-in)
- mostly asynchronous keystrokes thanks to UDP+stream protocol, so if you hit ^C it will abort stuff even if the screen is scrolling. Note that the way keystrokes are handled makes it susceptible to a timing attack, and there might have been work to mitigate this that i'm unaware of.
> so if you hit ^C it will abort stuff even if the screen is scrolling
I might be wrong, but AFAIK the fact that your terminal isn't handling this correctly already is due to a flow control setup problem somewhere in the chain (probably the terminal itself, as usually the server-side components are the most ancient): if your local console is only able to download and display and scroll data at a certain rate, it should "push back" on the server to get it to send you data at a slower rate, which in turn will push back on the terminal. When setup correctly, this flows all the way back to the original application, which will itself slow down whatever it is that it is doing.
I might be wrong, but AFAIK the fact that your terminal isn't handling this correctly already is due to a flow control setup problem somewhere in the chain (probably the terminal itself, as usually the server-side components are the most ancient): if your local console is only able to download and display and scroll data at a certain rate, it should "push back" on the server to get it to send you data at a slower rate, which in turn will push back on the terminal. When setup correctly, this flows all the way back to the original application, which will itself slow down whatever it is that it is doing.
its tcp congestion issues. ^C will work just fine locally.
it would also be ok if there were 2 tcp channels. or. udp. ;)
I don't mean locally: I mean that if you have all of your flow control stuff setup correctly, you shouldn't ever end up in the situation of "I hit ctrl-C to try to stop the massive stream of text, but this text was actually generated a minute ago and was streamed to me in a massive 10MB block and buffered in a bunch of sockets, so my ctrl-C is meaningless".
One thing that's distinctly better is that the backoff/recovery behavior of SSP (mosh's custom encrypted protocol, over UDP) works a lot better than TCP's. If I'm typing, and there's a network blip for e.g. thirty seconds (cell handoff), SSH will literally take minutes to get back to normal, and it'll be easier for me to kill SSH and restart the connection. mosh will recover much more quickly. TCP was written in the days when congestion on a shared Ethernet segment was a thing people actually ran into; with wireless and cell networks, that's not actually your protocol's biggest concern.
The common-case latency, when there's a good network connection, shouldn't differ much.
The common-case latency, when there's a good network connection, shouldn't differ much.
I wrap a normal OpenSSH connection in CurveCP.
CurveCP seems interesting (like most of djbs work). Would you get most of its client-side benefits (mobility support etc) if you'd create VPN over CurveCP? That way you wouldn't need to install it to the destination servers, but instead use a server with a stable, fast connection as a gateway.
Or is there some neat VPN solution that has good support for mobility already?
Or is there some neat VPN solution that has good support for mobility already?
Is there a neat VPN solution that would work through SSH ?
It is much easier to use one of the servers you have than pay for a VPN account to a provider.
It is much easier to use one of the servers you have than pay for a VPN account to a provider.
I used it for like 30 minutes before I realized there was no way to enable SSH agent forwarding.
I would love to see mosh-like solution, but client only.
Pretty much a wraper to ssh which will use screen plus some predictions. I guess it could get 80% of mosh benefits without the hassle of deploying new software on servers.
Pretty much a wraper to ssh which will use screen plus some predictions. I guess it could get 80% of mosh benefits without the hassle of deploying new software on servers.
I loved Mosh... until I started using it. Latency is definitely a big problem for me - even on fast connections. Often keystrokes arrive in the wrong order if you type too fast, making it useless.
Hi, thanks for your feedback! I have heard of this happening with iSSH's clean-room reimplementation of the protocol, but never with Mosh. Please file a bug report at https://github.com/keithw/mosh because we are eager to trace this down. (We have never heard of this happening to anybody, and it should not be possible if all is well.)
Most network programs lose their connections after roaming, including SSH and Web apps like Gmail.
Gmail.com has been a roaming-safe/disconnect-tolerant web app for quite some time now. It is even tolerant of huge disparities in time, as far as SSL will allow it to be.
I wonder what Gmail client they're talking about...
Gmail.com has been a roaming-safe/disconnect-tolerant web app for quite some time now. It is even tolerant of huge disparities in time, as far as SSL will allow it to be.
I wonder what Gmail client they're talking about...
Gmail often says "reconnecting" for me, and this does not always work correctly unless I manually tell it to "reconnect now".
I know this sounds not very secure, but since one of the best features of mosh is that you needn't install it, why not provide a place to download binaries for all platforms?