Please create an account to participate in the Slashdot moderation system


Forgot your password?

Mosh: Modernizing SSH With IP Roaming, Instant Local Echo 158

An anonymous reader writes "Launched in 1995, SSH quickly became the king of network login tools, supplanting the old insecure mainstays TELNET and RLOGIN. But 17 years later, a group of MIT hackers have come out with "mosh", which claims to modernize the most annoying parts of SSH. Mosh keeps its connection alive when clients roam among WiFi networks or switch to 3G, and gives instant feedback on typing (and deleting). No more annoying network lag on typing, the MIT boffins say, citing Bufferbloat, which has been increasing latencies." The folks involved have a pre-press research paper with the gritty details (to be presented at USENIX later this year). Mosh itself is not particularly exciting; the new State Synchronization Protocol it is based upon might be: "This is accomplished using a new protocol called the State Synchronization Protocol, for which Mosh is the first application. SSP runs over UDP, synchronizing the state of any object from one host to another. Datagrams are encrypted and authenticated using AES-128 in OCB mode. While SSP takes care of the networking protocol, it is the implementation of the object being synchronized that defines the ultimate semantics of the protocol."
This discussion has been archived. No new comments can be posted.

Mosh: Modernizing SSH With IP Roaming, Instant Local Echo

Comments Filter:
  • by ArsenneLupin ( 766289 ) on Wednesday April 11, 2012 @11:34AM (#39644631)
    ... a negotiable LOCAL_ECHO mode. Then they invented ssh, and left away that LOCAL_ECHO and linebuffered flags, considered to be archaic.

    And 15 years later, LOCAL_ECHO is back in mosh!

  • by Anrego ( 830717 ) * on Wednesday April 11, 2012 @11:35AM (#39644647)

    and gives instant feedback on typing (and deleting).

    That sounds like a step backwards to me. Any utility in that is lost when something doesn’t sync up properly. When I hit a key, I want to know it has been sent and received and see the result.. not see the result as my shell predicts it. Maybe I’m just having local echo flashbacks from past telnet experiences.

    Everything else sounds really neat though. I don’t jump wifi often enough for re-connecting and re-attaching to screen to be a big deal.. but I can see the utility for those who do.

  • by ZorinLynx ( 31751 ) on Wednesday April 11, 2012 @11:47AM (#39644815) Homepage

    If they implement their own TCP-like layer over UDP, there's no reason it can't be just as reliable.

    It's kind of hard to do things like roaming using TCP because endpoint IPs can change.

  • You, now:

    so I can ssh into every server, but only mosh into a few.

    You, 1995:

    so I can telnet into every server, but only ssh into a few.

  • Firewalls (Score:5, Insightful)

    by Alarash ( 746254 ) on Wednesday April 11, 2012 @12:12PM (#39645161)
    Reading the linked research paper a bit, and something strikes me.

    We use the existing infrastructure for authenticating hosts and users. To bootstrap an SSP connection, the user ïrst logs in to the remote host using conventional means, such as SSH or Kerberos. From there, the user or her script runs the server: an unprivileged process that chooses a random shared encryption key and begins listening on a UDP port. The server conveys the port number and key over the initial connection back to the client, which uses the information to start talking to the server over UDP.

    You open a SSH connection (client->server:22). This port is allowed on the firewall, it lets you through. But then the server decides to listen on UDP:(random port) and tells the client, back through the (encrypted) initial connection, which UDP port to contact. So you initiate a SSP UDP session on that port. How does the firewall knows it should let you through? Since the port number is communicated on an encrypted session, it doesn't have access to that information. So how does this work in a secure environment? The paper doesn't mention any mean for the server to communicate with the network which port its listening on.

  • by silanea ( 1241518 ) on Wednesday April 11, 2012 @02:02PM (#39646989)
    If we only ever built technology that appeared immediately useful for at least 95% of the population we would still be trying to figure out how to transport messages across long distances without using a horse.
  • by Anonymous Coward on Wednesday April 11, 2012 @03:10PM (#39648053)

    Modern shells have completion, and mosh is not going to predict that.

    It seems to me that for my typical usage it is going to have limited utility - I'm either in a shell where I'm leaning heavily on the tab for completion, or in vi where it would need to secondguess what vi is going to display.

Thus spake the master programmer: "When a program is being tested, it is too late to make design changes." -- Geoffrey James, "The Tao of Programming"