10 ms·

Mosh: A replacement for SSH

402 points by jayfk 12y ago

sagichmal 12y ago
Mosh is brilliant software. I use it every day. Being able to close my laptop, move to a different café, and open it back up with all of my sessions seamlessly reconnecting is invaluable. But -- mosh still can't do proper SSH agent forwarding[0], which is a real drag. Many of my common workflows become impossible. I hope it gets fixed! [0] https://github.com/keithw/mosh/issues/120 https://github.com/keithw/mosh/issues/120
- tjosten 12y ago
  /sign
- Maakuth 12y ago
  Yep, it's in my daily tools as well and very useful especially for 2G mobile connections, bad Wi-Fi and alike. It seems their development has pretty much stopped after initial spark of enthusiasm. Too bad, mosh-over-ssh and port forwarding would be pretty killer features for many scenarios.
- quotemstr 12y ago
  I feel like mosh is fixing problems at the wrong layer. Instead of making application protocols connectioness, we should make Mobile IP work so that connections don't need to be broken in the first place, or, failing that, separate the protocol management from the session persistence system. Combining regular ssh with screen has worked fine for me for years. Why would I want to switch to something with a much shorter track record for security? (By the way: if you want a line-buffered ssh for use over bad connections, run ssh inside Emacs with M-x shell.)
  - morsch 12y ago
    Yes. I was wondering, faced with an unreliable on-train mobile connection, is there any existing way to improve the content delivery by using a proxy host? It seemed to me as if the mobile browser kept redoing a whole lot of work, ie. essentially re-requesting web sites from scratch. I'd like to make a single request to a web site, have my proxy host complete the request and deliver the bytes piecemeal to the browser as I go in and out of range. I think it's possible to do this transparently to the browser, but I think you might need a proxy host with a reliable connection as well as a proxy software running on the mobile device that can deal with the situation by telling the reliable host: I'm back, here's a list of running requests and the last byte I received, please continue.
    - kyrra 12y ago
      I believe this is how the opera browser for ios works, or amazons browser for their fire tablet.
      - Piskvorrr 12y ago
        Alas, both of them are proprietary and monolithic - IOW, you can only use the infrastructure iff you're also using the one specific client. Not very useful for extending even for other browsers, or even different protocols - which is a pity :(
    - rakoo 12y ago
      He was mocked, but he was anticipating it: Stallman sends an email to a daemon that fetches the pages for him (https://stallman.org/stallman-computing.html https://stallman.org/stallman-computing.html) > I generally do not connect to web sites from my own machine, aside from a few sites I have some special relationship with. I fetch web pages from other sites by sending mail to a program (see git://git.gnu.org/womb/hacks.git) that fetches them, much like wget, and then mails them back to me. Then I look at them using a web browser, unless it is easy to see the text in the HTML page directly.
    - jdong 12y ago
      Lynx over mosh?
  - rweir 12y ago
    > I feel like mosh is fixing problems at the wrong layer. Instead of making application protocols connectioness, we should make Mobile IP work I look forward to using regular SSH to connect to my servers hosted in the floating city of New Chicago!
    - quotemstr 12y ago
      I'm still optimistic that we'll support RFC 6275 before we're all dead.
      - Piskvorrr 12y ago
        I for one hope that I won't need to support it after I'm dead.
        anonbanker 12y ago
        Let's assume for a moment that RFC6725 is implemented in pacemakers or artificial organs. How long after death would/should these devices remain active? could we use Mobile ipv6 to communicate with the recently-departed loved ones to send final well-wishes?
        Piskvorrr 12y ago
        Let us assume the moon is made of cheese. Now let's discuss the feasibility of a cheese-mining colony there. I, for one, look forward to communicating with a deceased person's gallbladder.
        anonbanker 12y ago
        https://warosu.org/data/vr/img/0014/96/1395782839524.jpg https://warosu.org/data/vr/img/0014/96/1395782839524.jpg Perhaps replying with a non-sequitor is why you were downvoted?
        Piskvorrr 12y ago
  - therealmarv 12y ago
    Thank you for the tip with "screen"! I was aware of MOSH but did not know about screen oO. Is there any other line-buffered ssh which does not require Emacs?
    - nolok 12y ago
      If you do not know screen, then tmux is going to blow your mind
      - matthiasv 12y ago
        If you do know screen, then tmux is going to blow your mind.
        jnbiche 12y ago
        Well, this is probably as good a place as any to ask a tough TMUX question I've had for several years. I love TMUX, but whenever I'm working with protocols or anything binary, if I accidentally push any binary out of stdout, it corrupts the display, and the only way I've figured out how to fix this once it's happened is to totally restart TMUX. Does anyone know how to fix this? (don't usually ask SO questions on HN but this has been bugging me for years)
        marcosdumay 12y ago
        I have very litle experience with TMUX... But you can try runnng the "reset" command. It resets the TTY, if TMUX does not use any crazy magic it should work.
        fmoralesc 12y ago
        Tried 'reset'?
        cel1ne 12y ago
        lesspipe [0] might fix your problem to some part. [0] http://www-zeuthen.desy.de/~friebel/unix/lesspipe.html http://www-zeuthen.desy.de/~friebel/unix/lesspipe.html
  - teddyh 12y ago
    (If all you’re using M-x shell for is to run SSH, it makes more sense to run M-x eshell, since that doesn’t waste a process for a subshell.)
  - rakoo 12y ago
    > we should make Mobile IP work Unfortunately we have very little chance of having an impact on how ip is implemented in mobile network, but we do have the possibility to change our softwares to accommodate deficiencies. Much like HTTP over SPDY is highly similar to HTTP over SCTP, but we have much more chance in making SPDY a reality rather than SCTP. > Combining regular ssh with screen has worked fine for me for years. I guess the real novelty (and it's too bad it isn't presented in greater depths) is SSP, the synchronization protocol. It can be an inspiration for other network programs.
  - takeda 12y ago
    There are already some solutions for this (and other problems). For example [NDN](http://en.wikipedia.org/wiki/Named_data_networking http://en.wikipedia.org/wiki/Named_data_networking) which was designed based on today's Internet usage pattern. The major problem with it is that existing protocols need to be reinvented once again to fit new way of communicating. Of course you could encapsulate TCP/IP over it, but then you're losing all nice properties of the protocol.
  - Spooky23 12y ago
    It's not going to happen, especially in mobile. ISPs like Verizon Mobile are NATing everything -- even IPv6 IPs, and running through proxy servers to enable rate-limiting and other things.
    - quotemstr 12y ago
      There is no reason that traffic shaping should require NAT.
      - andreasvc 12y ago
        "One IP per customer" makes accounting and bandwidth capping much easier.
        simoncion 12y ago
        "One IPv6 /64 per customer" works just as well, no?
  - e40 12y ago
    Combining regular ssh with screen has worked fine for me for years. This doesn't work for me because I use emacs over X11 over a tunnel. mosh doesn't work because I feel required to use ssh-agent. That is, I feel required to use a password on my ssh private key and not using ssh-agent is too high a burden.
    - fahadkhan 12y ago
      Have you tried xpra?
  - sandstrom 12y ago
    Although I like mosh, I agree that fixing this at a lower level would be better. What do you think about Multi-path? I think Apple is already using it for Siri. http://tools.ietf.org/html/rfc6824.html http://tools.ietf.org/html/rfc6824.html
  - boomlinde 12y ago
    > we should make Mobile IP work so that connections don't need to be broken in the first place A lot of the problems with mobile networking are the results of connections literally being cut off. On trains I often end up without coverage (tunnels, in the middle of nowhere) exactly for that reason; the connection broke. I don't think that hacking a system based on connections to pretend that this never happens is a particularly good idea.
  - gglitch 12y ago
    I run ssh inside emacs, and I also leave emacs running in server mode on my targets. I drop my signal, no big deal; I reconnect and reattach to emacs. No fuss, no muss, no lost work. It then becomes immense that I can do almost everything in emacs :)
- rmrz 12y ago
  Mosh is really great for avoiding disconnections and local echo. Lack of SSH agent forwarding was a problem for me as well, but I have found a workaround - I open a separate plain 'ssh -A' connection at the same time when I need my keys. On target machines I have SSH_AUTH_SOCK pointing to the stable well known location, which is a symlink to the unix socket recreated always by the last 'ssh -A' connection on the server. This allows me to use ssh from tmux session connected using mosh.
- pseudonym 12y ago
  If your workflow doesn't include tmux or screen, then I feel like your problem's already been answered. If you really wanted to, you could just add a "/bin/screen -DR; exit" to your remote .bashrc and the screen integration would be completely invisible after the initial instantiation. As far as mosh is concerned, it feels like it's an extremely overengineered solution to the "I wish I had started this process in a screen session" problem, except you need to be thinking even further ahead than you would normally (installing and connecting via a mosh service, as opposed to remembering to connect to a screen session that can be run with very little prior setup and no client modification).
  - gnufied 12y ago
    I have been using Screen for years. Will Screen attempt to reconnect to a remote SSH session? I think what `screen -DR` will do is - it will automatically connect me to a screen session `after` I login to the remote machine. But if I lost connectivity - my SSH session won't be auto-resumed from local machine in first place, I think thats one of the things `mosh` solves. It promises lower latency etc, but I am just perhaps too slow to notice such things (or both SSH/Mosh feel equally laggy if remote connection is slow enough).
    - pseudonym 12y ago
      >But if I lost connectivity - my SSH session won't be auto-resumed from local machine in first place, I think thats one of the things `mosh` solves. While true, it just seems (to me) that if that's the only problem you're solving (which is to say, not needing to type the command "ssh host" and let your key log you in) and it's at the expense of not being able to properly ForwardAgent (which I require very heavily in my line of work), then it's a lot of work for negative return. But, again, to each their own. As mentioned below, if your latency over a phone connection is so bad that this helps you, then by all means, use it. :) I'm just noting that for pretty much everyone I work with, this would be a step backwards.
    - Piskvorrr 12y ago
      Try autossh - a useful hack on top of ssh, which helps with the auto-resume issue, somewhat.
- zeroonetwothree 12y ago
  Yeah mosh is amazing. Just using screen isn't nearly as good because you still have restart the ssh connection. I usually have 5+ open at once so restarting them all is annoying.
- metafunctor 12y ago
  FWIW, there's this: https://github.com/rinne/mosh/tree/ssh-agent-forwarding https://github.com/rinne/mosh/tree/ssh-agent-forwarding I haven't used the agent forwarding patch myself, though. The patch is rather large, which may be the reason it was never merged. The author (rinne) is the former CTO of ssh.com, by the way.
  - kapilvt 12y ago
    Awesome, that would solve my main issue with mosh, here's the discussion on the pull request https://github.com/keithw/mosh/pull/423 https://github.com/keithw/mosh/pull/423
- MetaCosm 12y ago
  Mosh always seems oddly slow. I have a good connection to most of my servers (under 10ms to many, under 100ms to all)... and it just feels laggy, in vim sessions, in tmux scrollback, everywhere. I find just a vanilla ssh (with tmux always) to be far superior in terms of latency. I love the idea of mosh, but I find the implementation to be lacking... or I am doing it wrong. :)
  - andreasvc 12y ago
    That's odd. Regular ssh uses TCP while mosh uses UDP; perhaps there's some issue making UDP slower in your case?
- ryan-c 12y ago
  Are you aware that a forwarded agent can be used by anyone with access to your account (e.g. root) to authenticate as you? They can even re-forward your agent to their own computer.
- bascule 12y ago
  Agent forwarding is an antipattern, and insecure usage of it is prevalent. Forwarding it allows anyone who has root access on the remote system to impersonate you, and it can therefore be used to escalate privileges after a single system compromise. Alternatively, consider Kerberos and kinit.
phil_ips 12y ago
Was thinking before opening the link.. do we really need a replacement for SSH? > supports intermittent connectivity That's all you need to say really..!
- marcosdumay 12y ago
  Screen deals with intermittent connections just fine. I still don't see the need.
  - jdong 12y ago
    I don't think you've ever actually been on a bad connection. mosh has saved my ass more than once when I've been stuck with a satellite connection in the middle of nowhere. (Try fixing a failing loadbalancer while on a transatlantic cruise, using SSH)
    - xux 12y ago
      Why not just use Tmux or Screen?
      - jdong 12y ago
        Because even a small amount of packet loss makes SSH absolutely unusable (e.g making it completely freeze), whereas I've managed to function using mosh with around 30% packet loss.
  - sagichmal 12y ago
    You're ssh'd to a remote server and in a screen session. Actually, let's say you've got tmux going, and like four panes with different sessions to different hosts. Now, you close your laptop, hop on your bike, enjoy a nice lunch somewhere, and head to a café for the afternoon. You open your laptop again. Correct me if I'm wrong, but with your setup, you need to go to each pane and re-ssh to each host. But with mosh, I don't need to do anything except wait a few seconds. All of my connections are re-established, and (even without screen) my sessions are restored just as I left them.
zeograd 12y ago
Too bad mosh needs an udp port to run its own server. One of the greatness of ssh is its lean network requirements (it can even be considered https if seen from intermediate proxies, hence whitelisted) and this extra udp port is quite a burden in some environments. I still agree that mosh is a fine tool for mobile users. I'm just a tad worried about its security layer implementation being less audites than openssh for instance (as mosh isn't as widely used)...
- icebraining 12y ago
  Well, Mosh still uses OpenSSH for the initial authentication, and during the rest of the connection, all the security is handled by a single layer (AES-OCB, using the reference implementation), which is not specific to Mosh. That said, it has never been audited.
kolev 12y ago
It's not a replacement at all - it doesn't support scroll back (screen buffer). Latency often changes the order of keystrokes. I've tried to used it so many times and gave up every single time after the enthusiasm ran out.
- zobzu 12y ago
  one issue ive with mosh over time is that it doesnt timeout properly every time (it does most of the time after a long period). this keeps tmux/screen sessions attached "forever" which can be an issue with some programs that detect if you're detached to send notifications for example
- theon144 12y ago
  >Latency often changes the order of keystrokes. I've never had this experience! And I've used mosh for some time extensively on all sorts of connections ranging from abysmal to horrible. Maybe you used an older version?
  - kolev 12y ago
    Yes, it's been an issue in the past as I gave up on Mosh. To be fear, I will reinstall and try. Worst of all, I was having these issues on relatively fast connection, so, that's what turned me off as I could imagine when there are real latency issues in place.
- keeperofdakeys 12y ago
  The mosh protocol is specifically designed such that reordering won't happen (since it does use UDP as a base protocol, it requires this protection). I think they'd be very interested to hear about any such bugs you have regarding that. Also, as far as I was aware, ssh provided no scrollback either. Any such scrollback is a property of the (local) terminal you're using, not ssh itself.
  - Shish2k 12y ago
    > Any such scrollback is a property of the (local) terminal you're using, not ssh itself. The Mosh client is also a terminal emulator (similar to screen); part of the reason it can be so efficient is that it isn't just another layer in the network stack over which standard lines of text travel, it is a remote console viewer (like VNC is for graphical desktops, only sending parts of the desktop that have changed; and if there is a massive wall of text spamming the screen, it will just show you the end result rather than sending it all)
zhovner 12y ago
Scrolling still not working?
- denibertovic 12y ago
  Not sure what you mean. scrolling works just fine for me. I use mosh and screen together though.
- dedward 12y ago
  And it likely won't.. at least not without giving up the ability to work over high latency/lossy connections properly. The reason mosh shows you current-state rather than playing catch up with every byte transmitted by the terminal is very deliberate, and desired.
- andreasvc 12y ago
  Use screen/tmux.
- deleted 12y ago
  [deleted]
zobzu 12y ago
are those links becoming invalidated after 3month and auto reposted or something ? This URL must have shown up like 3 times on the front page in the past year alone
emikulic 12y ago
I wish half of this had been implemented in tmux instead. tmux is already client/server, add local typeahead (which is very cool) to the client and let me run it over whatever transport I want (spoiler: it will still be ssh, because I don't really benefit that much from their reinvention of TCP)
- sina 12y ago
  Both "client" and "server" in TMUX terminology are on the same machine. AFAIK, MOSH creates a terminal emulator in each connected machine and keeps them in sync.
hbbio 12y ago
In French, Mosh is exactly pronounced as "moche" which means ugly. Of course, this doesn't change anything in the project interest!
- pbhjpbhj 12y ago
  In en-gb it means wild, aggressive dancing synonymous with the stage-front area dancing at a heavy-metal concert. http://en.wiktionary.org/wiki/mosh http://en.wiktionary.org/wiki/mosh
plicense 12y ago
Aw, fonts - http://imgur.com/v9E9vOY http://imgur.com/v9E9vOY, the full stop under the P.
blueskin_ 12y ago
My main issue with mosh is having to open a massive UDP port range, which just goes against my instinct when it comes to security. The other security issue is the whole 'seamless reconnect' - it's probably been thought of, but does anyone have any links to how they've mitigated the massive MITM risk this opens users to?
- skrause 12y ago
  You don't actually need to open a UDP port range, a single UDP port is enough. But then you'll have to tell mosh with the -p parameter which port it has to use.
Gonzih 12y ago
How it can be replacement if it uses ssh to start daemon on server to listen on UDP port? But yes, it's great. Still not perfect, still issues with non unicode chars sometime, still some issues with rendering from time to time.
- rspeer 12y ago
  > still issues with non unicode chars sometime What's a non-Unicode character, and where would you find one? Do you mean the crazy private use characters used to make fancy Vim status lines, or something else?
teamhappy 12y ago
Still one of of my favourite tech talks. Mosh is great too.
theandrewbailey 12y ago
Getting 403 forbidden, so have some cache: https://webcache.googleusercontent.com/search?q=cache:Sb3IKAMHCSEJ:https://mosh.mit.edu/+&cd=1 https://webcache.googleusercontent.com/search?q=cache:Sb3IKA...
hf 12y ago
Mosh is a truly impressive feat of thought and, perhaps more importantly, engineering. The thinking behind Mosh is substantial, the paradigms are fresh. Reading about mosh on its excellent website, I always leave with a profound feeling of enthusiasm. Mosh belongs a school of software development ethics that I'm sorely missing in the world. However, I do concur that, perhaps, Mosh solves a deep problem on the wrong level or, even, in the wrong domain. The feeling, already expressed here, that "tmux oughta do it" never leaves me. Why is that? Because I know that ssh, by itsself, can handle connection loss quite well[0]. Rather, I suspect, ssh can't deal with IP changes or the destruction of the underlying interface. So, here's the rub: Why is a stable, somehow-abstract, network interface with a local IP, sitting on top of the actual network interfaces, be they wired or wireless, not the answer? Over the years, on and off, I tried to get the Linux ethernet bonding stack (ifenslave) to provide me with just that solution, but was never able to. Hence, I keep revisiting mosh, then revisiting ifenslave... [0] On a machine that doesn't dynamically switch network interfaces on demand, just unplug an ethernet cable, wait a while and plug it back in: your ssh session will resume.
- apk17 12y ago
  Mobile IP etc. solve the problem of changing IP addresses, but they don't address the flakiness of mobile connections (esp. when actually mobile). TCP takes some time to come back; having a faster mechanisms is much appreciated when your link loses a few packets twice every minute.
- pferde 12y ago
  I believe http://multipath-tcp.org/ http://multipath-tcp.org/ is the answer.
- bascule 12y ago
  Mosh implements a delta algorithm between the server's buffer and the client's buffer. This means if packet loss is occurring, to sync back up, the server only needs to send the delta of its state to the client. SSH, on the other hand, is stream-oriented, and will replay everything that has occurred, even if the resulting changes to the display in the end are minimal. It's similar to how something like VNC functions compared to the X11 protocol. The VNC protocol is more efficient and tolerant of lossy or low-latency connections.
xxdesmus 12y ago
Nice repost? Posts about Mosh from 2 years ago: https://news.ycombinator.com/item?id=3819382 https://news.ycombinator.com/item?id=3819382 https://news.ycombinator.com/item?id=5016745 https://news.ycombinator.com/item?id=5016745 https://news.ycombinator.com/item?id=3871687 https://news.ycombinator.com/item?id=3871687 https://news.ycombinator.com/item?id=3814589 https://news.ycombinator.com/item?id=3814589 ...just to name a few examples. Mosh is awesome, but also not something new.
- joshbaptiste 12y ago
  Reposts are fine, gets the blood flowing again. I totally forgot about Mosh and decided to watch the awesome presentation on their website, also decided to enable on my tablet via JuiceSSH.
- dang 12y ago
  A few reposts are ok if the story hasn't had significant attention on HN in the last year or so: https://news.ycombinator.com/newsfaq.html https://news.ycombinator.com/newsfaq.html. https://news.ycombinator.com/item?id=6321474 https://news.ycombinator.com/item?id=6321474 was within a year, but I guess was borderline, so we'll leave the current post.
  - xxdesmus 12y ago
    gotcha, thanks for the clarification. Mosh continues to be awesome, and definitely deserves to be more well known. It works wonders when you have a crappy connection.
lasermike026 12y ago
Has security review been done?
- icebraining 12y ago
  No: Q: Has your secure datagram protocol been audited by experts? No. Mosh is actively used and has been read over by security- minded crypto nerds who think its design is reasonable, but any novel datagram protocol is going to have to prove itself, and SSP is no exception. We use the reference implementations of AES-128 and OCB, and we welcome your eyes on the code. We think the radical simplicity of the design is an advantage, but of course others have thought that and have been wrong. We don't doubt it will (properly!) take time for the security community to get comfortable with mosh.
sjackso 12y ago
Several commenters are asking what mosh provides that's better than ssh+screen/tmux. A few years ago I spent a summer at a remote field site, sharing a flaky T1 with 100 other people over equally flaky site-wide wireless network. (Many of those people were undergraduates who had been politely asked not to use the research network to access facebook, but, well, you know.) Not only was packet loss common, but latencies to an outside host varied whimsically from 50ms to 2000ms. In those conditions ssh was unusable, tmux or not. I was able to do work on remote servers only because of mosh.
- ryan-c 12y ago
  Let me clarify a little more. Mosh hides latency by doing display prediction. It guesses what the results of your keystrokes will be and displays them locally, highlighted as predicted with an underscore.
dllthomas 12y ago
I actually find lack of local echo somewhat valuable. When my connection is spotty, that gives me immediate feedback about what is and is not getting through.
- sjackso 12y ago
  You get similar feedback when using mosh -- text that is echoed locally but has not yet reached the remote host is displayed with an underline. On a bad connection, you see underlined text promptly as you type, and the underline gradually disappears as the network catches up.
  - dllthomas 12y ago
    Ah, great!
afarrell 12y ago
I have been using mosh for two years now and it has greatly improved my life. It means that rather than buying a brand-new laptop, I can just connect to a $5/mo linode with an SSD and program on that.
pbhjpbhj 12y ago
FYI to install on Kubuntu 14.04 I only needed to "sudo apt-get install mosh" to get mosh 1.2.4a.
snvzz 12y ago
Mosh is nice, but "A replacement for SSH" is quite stretching it, considering it does use ssh to setup its own connection and so it depends on SSH. It also doesn't provide most of SSH functionality, and it doesn't support IPv6 yet, whereas SSH does.
nieve 12y ago
My biggest complaint about Mosh is that how it handles the login sequence breaks common .bashrc/.bash_profile idioms like test -z "$BASHPROFILEREAD" || return (to avoid double-sourcing) and there's no good way to fix them. I haven't tested ksh93/zsh yet, but I suspect similar issues. I suspect the developers do little more with their shell initialization than set a few aliases and variables so it's not an issue for them, but fixing it for myself is far more work than worth it. It's too bad, everything else works well for me with mosh.

402 points by jayfk 12y ago

Mosh is brilliant software. I use it every day. Being able to close my laptop, move to a different café, and open it back up with all of my sessions seamlessly reconnecting is invaluable. But -- mosh still can't do proper SSH agent forwarding[0], which is a real drag. Many of my common workflows become impossible. I hope it gets fixed! [0] https://github.com/keithw/mosh/issues/120 https://github.com/keithw/mosh/issues/120

tjosten 12y ago
/sign
Maakuth 12y ago
Yep, it's in my daily tools as well and very useful especially for 2G mobile connections, bad Wi-Fi and alike. It seems their development has pretty much stopped after initial spark of enthusiasm. Too bad, mosh-over-ssh and port forwarding would be pretty killer features for many scenarios.
quotemstr 12y ago
I feel like mosh is fixing problems at the wrong layer. Instead of making application protocols connectioness, we should make Mobile IP work so that connections don't need to be broken in the first place, or, failing that, separate the protocol management from the session persistence system. Combining regular ssh with screen has worked fine for me for years. Why would I want to switch to something with a much shorter track record for security? (By the way: if you want a line-buffered ssh for use over bad connections, run ssh inside Emacs with M-x shell.)
- morsch 12y ago
  Yes. I was wondering, faced with an unreliable on-train mobile connection, is there any existing way to improve the content delivery by using a proxy host? It seemed to me as if the mobile browser kept redoing a whole lot of work, ie. essentially re-requesting web sites from scratch. I'd like to make a single request to a web site, have my proxy host complete the request and deliver the bytes piecemeal to the browser as I go in and out of range. I think it's possible to do this transparently to the browser, but I think you might need a proxy host with a reliable connection as well as a proxy software running on the mobile device that can deal with the situation by telling the reliable host: I'm back, here's a list of running requests and the last byte I received, please continue.
  - kyrra 12y ago
    I believe this is how the opera browser for ios works, or amazons browser for their fire tablet.
    - Piskvorrr 12y ago
      Alas, both of them are proprietary and monolithic - IOW, you can only use the infrastructure iff you're also using the one specific client. Not very useful for extending even for other browsers, or even different protocols - which is a pity :(
  - rakoo 12y ago
    He was mocked, but he was anticipating it: Stallman sends an email to a daemon that fetches the pages for him (https://stallman.org/stallman-computing.html https://stallman.org/stallman-computing.html) > I generally do not connect to web sites from my own machine, aside from a few sites I have some special relationship with. I fetch web pages from other sites by sending mail to a program (see git://git.gnu.org/womb/hacks.git) that fetches them, much like wget, and then mails them back to me. Then I look at them using a web browser, unless it is easy to see the text in the HTML page directly.
  - jdong 12y ago
    Lynx over mosh?
- rweir 12y ago
  > I feel like mosh is fixing problems at the wrong layer. Instead of making application protocols connectioness, we should make Mobile IP work I look forward to using regular SSH to connect to my servers hosted in the floating city of New Chicago!
  - quotemstr 12y ago
    I'm still optimistic that we'll support RFC 6275 before we're all dead.
    - Piskvorrr 12y ago
      I for one hope that I won't need to support it after I'm dead.
      - anonbanker 12y ago
        Let's assume for a moment that RFC6725 is implemented in pacemakers or artificial organs. How long after death would/should these devices remain active? could we use Mobile ipv6 to communicate with the recently-departed loved ones to send final well-wishes?
        Piskvorrr 12y ago
        Let us assume the moon is made of cheese. Now let's discuss the feasibility of a cheese-mining colony there. I, for one, look forward to communicating with a deceased person's gallbladder.
        anonbanker 12y ago
        https://warosu.org/data/vr/img/0014/96/1395782839524.jpg https://warosu.org/data/vr/img/0014/96/1395782839524.jpg Perhaps replying with a non-sequitor is why you were downvoted?
        Piskvorrr 12y ago
- therealmarv 12y ago
  Thank you for the tip with "screen"! I was aware of MOSH but did not know about screen oO. Is there any other line-buffered ssh which does not require Emacs?
  - nolok 12y ago
    If you do not know screen, then tmux is going to blow your mind
    - matthiasv 12y ago
      If you do know screen, then tmux is going to blow your mind.
      - jnbiche 12y ago
        Well, this is probably as good a place as any to ask a tough TMUX question I've had for several years. I love TMUX, but whenever I'm working with protocols or anything binary, if I accidentally push any binary out of stdout, it corrupts the display, and the only way I've figured out how to fix this once it's happened is to totally restart TMUX. Does anyone know how to fix this? (don't usually ask SO questions on HN but this has been bugging me for years)
        marcosdumay 12y ago
        I have very litle experience with TMUX... But you can try runnng the "reset" command. It resets the TTY, if TMUX does not use any crazy magic it should work.
        fmoralesc 12y ago
        Tried 'reset'?
        cel1ne 12y ago
        lesspipe [0] might fix your problem to some part. [0] http://www-zeuthen.desy.de/~friebel/unix/lesspipe.html http://www-zeuthen.desy.de/~friebel/unix/lesspipe.html
- teddyh 12y ago
  (If all you’re using M-x shell for is to run SSH, it makes more sense to run M-x eshell, since that doesn’t waste a process for a subshell.)
- rakoo 12y ago
  > we should make Mobile IP work Unfortunately we have very little chance of having an impact on how ip is implemented in mobile network, but we do have the possibility to change our softwares to accommodate deficiencies. Much like HTTP over SPDY is highly similar to HTTP over SCTP, but we have much more chance in making SPDY a reality rather than SCTP. > Combining regular ssh with screen has worked fine for me for years. I guess the real novelty (and it's too bad it isn't presented in greater depths) is SSP, the synchronization protocol. It can be an inspiration for other network programs.
- takeda 12y ago
  There are already some solutions for this (and other problems). For example [NDN](http://en.wikipedia.org/wiki/Named_data_networking http://en.wikipedia.org/wiki/Named_data_networking) which was designed based on today's Internet usage pattern. The major problem with it is that existing protocols need to be reinvented once again to fit new way of communicating. Of course you could encapsulate TCP/IP over it, but then you're losing all nice properties of the protocol.
- Spooky23 12y ago
  It's not going to happen, especially in mobile. ISPs like Verizon Mobile are NATing everything -- even IPv6 IPs, and running through proxy servers to enable rate-limiting and other things.
  - quotemstr 12y ago
    There is no reason that traffic shaping should require NAT.
    - andreasvc 12y ago
      "One IP per customer" makes accounting and bandwidth capping much easier.
      - simoncion 12y ago
        "One IPv6 /64 per customer" works just as well, no?
- e40 12y ago
  Combining regular ssh with screen has worked fine for me for years. This doesn't work for me because I use emacs over X11 over a tunnel. mosh doesn't work because I feel required to use ssh-agent. That is, I feel required to use a password on my ssh private key and not using ssh-agent is too high a burden.
  - fahadkhan 12y ago
    Have you tried xpra?
- sandstrom 12y ago
  Although I like mosh, I agree that fixing this at a lower level would be better. What do you think about Multi-path? I think Apple is already using it for Siri. http://tools.ietf.org/html/rfc6824.html http://tools.ietf.org/html/rfc6824.html
- boomlinde 12y ago
  > we should make Mobile IP work so that connections don't need to be broken in the first place A lot of the problems with mobile networking are the results of connections literally being cut off. On trains I often end up without coverage (tunnels, in the middle of nowhere) exactly for that reason; the connection broke. I don't think that hacking a system based on connections to pretend that this never happens is a particularly good idea.
- gglitch 12y ago
  I run ssh inside emacs, and I also leave emacs running in server mode on my targets. I drop my signal, no big deal; I reconnect and reattach to emacs. No fuss, no muss, no lost work. It then becomes immense that I can do almost everything in emacs :)
rmrz 12y ago
Mosh is really great for avoiding disconnections and local echo. Lack of SSH agent forwarding was a problem for me as well, but I have found a workaround - I open a separate plain 'ssh -A' connection at the same time when I need my keys. On target machines I have SSH_AUTH_SOCK pointing to the stable well known location, which is a symlink to the unix socket recreated always by the last 'ssh -A' connection on the server. This allows me to use ssh from tmux session connected using mosh.
pseudonym 12y ago
If your workflow doesn't include tmux or screen, then I feel like your problem's already been answered. If you really wanted to, you could just add a "/bin/screen -DR; exit" to your remote .bashrc and the screen integration would be completely invisible after the initial instantiation. As far as mosh is concerned, it feels like it's an extremely overengineered solution to the "I wish I had started this process in a screen session" problem, except you need to be thinking even further ahead than you would normally (installing and connecting via a mosh service, as opposed to remembering to connect to a screen session that can be run with very little prior setup and no client modification).
- gnufied 12y ago
  I have been using Screen for years. Will Screen attempt to reconnect to a remote SSH session? I think what `screen -DR` will do is - it will automatically connect me to a screen session `after` I login to the remote machine. But if I lost connectivity - my SSH session won't be auto-resumed from local machine in first place, I think thats one of the things `mosh` solves. It promises lower latency etc, but I am just perhaps too slow to notice such things (or both SSH/Mosh feel equally laggy if remote connection is slow enough).
  - pseudonym 12y ago
    >But if I lost connectivity - my SSH session won't be auto-resumed from local machine in first place, I think thats one of the things `mosh` solves. While true, it just seems (to me) that if that's the only problem you're solving (which is to say, not needing to type the command "ssh host" and let your key log you in) and it's at the expense of not being able to properly ForwardAgent (which I require very heavily in my line of work), then it's a lot of work for negative return. But, again, to each their own. As mentioned below, if your latency over a phone connection is so bad that this helps you, then by all means, use it. :) I'm just noting that for pretty much everyone I work with, this would be a step backwards.
  - Piskvorrr 12y ago
    Try autossh - a useful hack on top of ssh, which helps with the auto-resume issue, somewhat.
zeroonetwothree 12y ago
Yeah mosh is amazing. Just using screen isn't nearly as good because you still have restart the ssh connection. I usually have 5+ open at once so restarting them all is annoying.
metafunctor 12y ago
FWIW, there's this: https://github.com/rinne/mosh/tree/ssh-agent-forwarding https://github.com/rinne/mosh/tree/ssh-agent-forwarding I haven't used the agent forwarding patch myself, though. The patch is rather large, which may be the reason it was never merged. The author (rinne) is the former CTO of ssh.com, by the way.
- kapilvt 12y ago
  Awesome, that would solve my main issue with mosh, here's the discussion on the pull request https://github.com/keithw/mosh/pull/423 https://github.com/keithw/mosh/pull/423
MetaCosm 12y ago
Mosh always seems oddly slow. I have a good connection to most of my servers (under 10ms to many, under 100ms to all)... and it just feels laggy, in vim sessions, in tmux scrollback, everywhere. I find just a vanilla ssh (with tmux always) to be far superior in terms of latency. I love the idea of mosh, but I find the implementation to be lacking... or I am doing it wrong. :)
- andreasvc 12y ago
  That's odd. Regular ssh uses TCP while mosh uses UDP; perhaps there's some issue making UDP slower in your case?
ryan-c 12y ago
Are you aware that a forwarded agent can be used by anyone with access to your account (e.g. root) to authenticate as you? They can even re-forward your agent to their own computer.
bascule 12y ago
Agent forwarding is an antipattern, and insecure usage of it is prevalent. Forwarding it allows anyone who has root access on the remote system to impersonate you, and it can therefore be used to escalate privileges after a single system compromise. Alternatively, consider Kerberos and kinit.

phil_ips 12y ago

Was thinking before opening the link.. do we really need a replacement for SSH? > supports intermittent connectivity That's all you need to say really..!

marcosdumay 12y ago
Screen deals with intermittent connections just fine. I still don't see the need.
- jdong 12y ago
  I don't think you've ever actually been on a bad connection. mosh has saved my ass more than once when I've been stuck with a satellite connection in the middle of nowhere. (Try fixing a failing loadbalancer while on a transatlantic cruise, using SSH)
  - xux 12y ago
    Why not just use Tmux or Screen?
    - jdong 12y ago
      Because even a small amount of packet loss makes SSH absolutely unusable (e.g making it completely freeze), whereas I've managed to function using mosh with around 30% packet loss.
- sagichmal 12y ago
  You're ssh'd to a remote server and in a screen session. Actually, let's say you've got tmux going, and like four panes with different sessions to different hosts. Now, you close your laptop, hop on your bike, enjoy a nice lunch somewhere, and head to a café for the afternoon. You open your laptop again. Correct me if I'm wrong, but with your setup, you need to go to each pane and re-ssh to each host. But with mosh, I don't need to do anything except wait a few seconds. All of my connections are re-established, and (even without screen) my sessions are restored just as I left them.

zeograd 12y ago

Too bad mosh needs an udp port to run its own server. One of the greatness of ssh is its lean network requirements (it can even be considered https if seen from intermediate proxies, hence whitelisted) and this extra udp port is quite a burden in some environments. I still agree that mosh is a fine tool for mobile users. I'm just a tad worried about its security layer implementation being less audites than openssh for instance (as mosh isn't as widely used)...

icebraining 12y ago
Well, Mosh still uses OpenSSH for the initial authentication, and during the rest of the connection, all the security is handled by a single layer (AES-OCB, using the reference implementation), which is not specific to Mosh. That said, it has never been audited.

kolev 12y ago

It's not a replacement at all - it doesn't support scroll back (screen buffer). Latency often changes the order of keystrokes. I've tried to used it so many times and gave up every single time after the enthusiasm ran out.

zobzu 12y ago
one issue ive with mosh over time is that it doesnt timeout properly every time (it does most of the time after a long period). this keeps tmux/screen sessions attached "forever" which can be an issue with some programs that detect if you're detached to send notifications for example
theon144 12y ago
>Latency often changes the order of keystrokes. I've never had this experience! And I've used mosh for some time extensively on all sorts of connections ranging from abysmal to horrible. Maybe you used an older version?
- kolev 12y ago
  Yes, it's been an issue in the past as I gave up on Mosh. To be fear, I will reinstall and try. Worst of all, I was having these issues on relatively fast connection, so, that's what turned me off as I could imagine when there are real latency issues in place.
keeperofdakeys 12y ago
The mosh protocol is specifically designed such that reordering won't happen (since it does use UDP as a base protocol, it requires this protection). I think they'd be very interested to hear about any such bugs you have regarding that. Also, as far as I was aware, ssh provided no scrollback either. Any such scrollback is a property of the (local) terminal you're using, not ssh itself.
- Shish2k 12y ago
  > Any such scrollback is a property of the (local) terminal you're using, not ssh itself. The Mosh client is also a terminal emulator (similar to screen); part of the reason it can be so efficient is that it isn't just another layer in the network stack over which standard lines of text travel, it is a remote console viewer (like VNC is for graphical desktops, only sending parts of the desktop that have changed; and if there is a massive wall of text spamming the screen, it will just show you the end result rather than sending it all)

zhovner 12y ago

Scrolling still not working?

denibertovic 12y ago
Not sure what you mean. scrolling works just fine for me. I use mosh and screen together though.
dedward 12y ago
And it likely won't.. at least not without giving up the ability to work over high latency/lossy connections properly. The reason mosh shows you current-state rather than playing catch up with every byte transmitted by the terminal is very deliberate, and desired.
andreasvc 12y ago
Use screen/tmux.
deleted 12y ago
[deleted]

zobzu 12y ago

are those links becoming invalidated after 3month and auto reposted or something ? This URL must have shown up like 3 times on the front page in the past year alone

emikulic 12y ago

I wish half of this had been implemented in tmux instead. tmux is already client/server, add local typeahead (which is very cool) to the client and let me run it over whatever transport I want (spoiler: it will still be ssh, because I don't really benefit that much from their reinvention of TCP)

sina 12y ago
Both "client" and "server" in TMUX terminology are on the same machine. AFAIK, MOSH creates a terminal emulator in each connected machine and keeps them in sync.

hbbio 12y ago

In French, Mosh is exactly pronounced as "moche" which means ugly. Of course, this doesn't change anything in the project interest!

pbhjpbhj 12y ago
In en-gb it means wild, aggressive dancing synonymous with the stage-front area dancing at a heavy-metal concert. http://en.wiktionary.org/wiki/mosh http://en.wiktionary.org/wiki/mosh

plicense 12y ago

Aw, fonts - http://imgur.com/v9E9vOY http://imgur.com/v9E9vOY, the full stop under the P.

blueskin_ 12y ago

My main issue with mosh is having to open a massive UDP port range, which just goes against my instinct when it comes to security. The other security issue is the whole 'seamless reconnect' - it's probably been thought of, but does anyone have any links to how they've mitigated the massive MITM risk this opens users to?

skrause 12y ago
You don't actually need to open a UDP port range, a single UDP port is enough. But then you'll have to tell mosh with the -p parameter which port it has to use.

Gonzih 12y ago

How it can be replacement if it uses ssh to start daemon on server to listen on UDP port? But yes, it's great. Still not perfect, still issues with non unicode chars sometime, still some issues with rendering from time to time.

rspeer 12y ago
> still issues with non unicode chars sometime What's a non-Unicode character, and where would you find one? Do you mean the crazy private use characters used to make fancy Vim status lines, or something else?

teamhappy 12y ago

Still one of of my favourite tech talks. Mosh is great too.

theandrewbailey 12y ago

Getting 403 forbidden, so have some cache: https://webcache.googleusercontent.com/search?q=cache:Sb3IKAMHCSEJ:https://mosh.mit.edu/+&cd=1 https://webcache.googleusercontent.com/search?q=cache:Sb3IKA...

hf 12y ago

Mosh is a truly impressive feat of thought and, perhaps more importantly, engineering. The thinking behind Mosh is substantial, the paradigms are fresh. Reading about mosh on its excellent website, I always leave with a profound feeling of enthusiasm. Mosh belongs a school of software development ethics that I'm sorely missing in the world. However, I do concur that, perhaps, Mosh solves a deep problem on the wrong level or, even, in the wrong domain. The feeling, already expressed here, that "tmux oughta do it" never leaves me. Why is that? Because I know that ssh, by itsself, can handle connection loss quite well[0]. Rather, I suspect, ssh can't deal with IP changes or the destruction of the underlying interface. So, here's the rub: Why is a stable, somehow-abstract, network interface with a local IP, sitting on top of the actual network interfaces, be they wired or wireless, not the answer? Over the years, on and off, I tried to get the Linux ethernet bonding stack (ifenslave) to provide me with just that solution, but was never able to. Hence, I keep revisiting mosh, then revisiting ifenslave... [0] On a machine that doesn't dynamically switch network interfaces on demand, just unplug an ethernet cable, wait a while and plug it back in: your ssh session will resume.

apk17 12y ago
Mobile IP etc. solve the problem of changing IP addresses, but they don't address the flakiness of mobile connections (esp. when actually mobile). TCP takes some time to come back; having a faster mechanisms is much appreciated when your link loses a few packets twice every minute.
pferde 12y ago
I believe http://multipath-tcp.org/ http://multipath-tcp.org/ is the answer.
bascule 12y ago
Mosh implements a delta algorithm between the server's buffer and the client's buffer. This means if packet loss is occurring, to sync back up, the server only needs to send the delta of its state to the client. SSH, on the other hand, is stream-oriented, and will replay everything that has occurred, even if the resulting changes to the display in the end are minimal. It's similar to how something like VNC functions compared to the X11 protocol. The VNC protocol is more efficient and tolerant of lossy or low-latency connections.

xxdesmus 12y ago

Nice repost? Posts about Mosh from 2 years ago: https://news.ycombinator.com/item?id=3819382 https://news.ycombinator.com/item?id=3819382 https://news.ycombinator.com/item?id=5016745 https://news.ycombinator.com/item?id=5016745 https://news.ycombinator.com/item?id=3871687 https://news.ycombinator.com/item?id=3871687 https://news.ycombinator.com/item?id=3814589 https://news.ycombinator.com/item?id=3814589 ...just to name a few examples. Mosh is awesome, but also not something new.

joshbaptiste 12y ago
Reposts are fine, gets the blood flowing again. I totally forgot about Mosh and decided to watch the awesome presentation on their website, also decided to enable on my tablet via JuiceSSH.
dang 12y ago
A few reposts are ok if the story hasn't had significant attention on HN in the last year or so: https://news.ycombinator.com/newsfaq.html https://news.ycombinator.com/newsfaq.html. https://news.ycombinator.com/item?id=6321474 https://news.ycombinator.com/item?id=6321474 was within a year, but I guess was borderline, so we'll leave the current post.
- xxdesmus 12y ago
  gotcha, thanks for the clarification. Mosh continues to be awesome, and definitely deserves to be more well known. It works wonders when you have a crappy connection.

lasermike026 12y ago

Has security review been done?

icebraining 12y ago
No: Q: Has your secure datagram protocol been audited by experts? No. Mosh is actively used and has been read over by security- minded crypto nerds who think its design is reasonable, but any novel datagram protocol is going to have to prove itself, and SSP is no exception. We use the reference implementations of AES-128 and OCB, and we welcome your eyes on the code. We think the radical simplicity of the design is an advantage, but of course others have thought that and have been wrong. We don't doubt it will (properly!) take time for the security community to get comfortable with mosh.

sjackso 12y ago

Several commenters are asking what mosh provides that's better than ssh+screen/tmux. A few years ago I spent a summer at a remote field site, sharing a flaky T1 with 100 other people over equally flaky site-wide wireless network. (Many of those people were undergraduates who had been politely asked not to use the research network to access facebook, but, well, you know.) Not only was packet loss common, but latencies to an outside host varied whimsically from 50ms to 2000ms. In those conditions ssh was unusable, tmux or not. I was able to do work on remote servers only because of mosh.

ryan-c 12y ago
Let me clarify a little more. Mosh hides latency by doing display prediction. It guesses what the results of your keystrokes will be and displays them locally, highlighted as predicted with an underscore.

dllthomas 12y ago

I actually find lack of local echo somewhat valuable. When my connection is spotty, that gives me immediate feedback about what is and is not getting through.

sjackso 12y ago
You get similar feedback when using mosh -- text that is echoed locally but has not yet reached the remote host is displayed with an underline. On a bad connection, you see underlined text promptly as you type, and the underline gradually disappears as the network catches up.
- dllthomas 12y ago
  Ah, great!

afarrell 12y ago

I have been using mosh for two years now and it has greatly improved my life. It means that rather than buying a brand-new laptop, I can just connect to a $5/mo linode with an SSD and program on that.

pbhjpbhj 12y ago

FYI to install on Kubuntu 14.04 I only needed to "sudo apt-get install mosh" to get mosh 1.2.4a.

snvzz 12y ago

Mosh is nice, but "A replacement for SSH" is quite stretching it, considering it does use ssh to setup its own connection and so it depends on SSH. It also doesn't provide most of SSH functionality, and it doesn't support IPv6 yet, whereas SSH does.

nieve 12y ago

My biggest complaint about Mosh is that how it handles the login sequence breaks common .bashrc/.bash_profile idioms like test -z "$BASHPROFILEREAD" || return (to avoid double-sourcing) and there's no good way to fix them. I haven't tested ksh93/zsh yet, but I suspect similar issues. I suspect the developers do little more with their shell initialization than set a few aliases and variables so it's not an issue for them, but fixing it for myself is far more work than worth it. It's too bad, everything else works well for me with mosh.