17 ms·

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

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.

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.