Slashdot Mirror

← Back to Stories (view on slashdot.org)

Mosh: Modernizing SSH With IP Roaming, Instant Local Echo

Posted by Unknown on from the udp-reunion-tour dept.

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."

15 of 158 comments (clear)

  1. First they invented telnet, which had... by ArsenneLupin · · Score: 4, Insightful
    ... 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!

    1. Re:First they invented telnet, which had... by Animats · · Score: 4, Interesting

      .. 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!

      Right. Breaking local echo in Telnet was a Berkeley misfeature. It was in 3COM's UNET, which predated Berkley networking in UNIX. (Berkeley did not introduce networking in UNIX. Theirs was the third or fourth implementation, after ones from BBN, 3COM, and Phil Karn.) With UNET, circa 1983, Telnet had local echo until you used something like VI or the RAND full screen editor, at which point the server noticed the stty call which switched to "raw mode" and switched to remote echo.

      Seamless transition from local echo to remote echo is even older. It was in Tymnet, which used markers called a "red ball" and a "green ball" to do the switch seamlessly.

  2. Pass on the local echo please! by Anrego · · Score: 5, Insightful

    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.

    1. Re:Pass on the local echo please! by Anonymous Coward · · Score: 5, Informative

      From their website:

      Disable instant echo

      $ mosh --predict=never niennunb

      The -n switch is a synonym. By contrast, passing --predict=always or -a will enable instant local echo even on low-delay links.

      Sounds like it tries to be smart about this, but not so smart as to not allow a human to force things the way he wants them.

    2. Re:Pass on the local echo please! by Anonymous Coward · · Score: 5, Informative

      According to their website, locally echoed but not yet synced input is visually distinct from synced content, so you'll always know what has been sent and what hasn't.

    3. Re:Pass on the local echo please! by Anonymous Coward · · Score: 5, Informative

      I've been using it for a few days now, and I find the local echo to be quite a useful feature. Many of the machines I remotely use are on different continents, and waiting for my keypress to make a round trip can be frustrating at times.

      Mosh also makes it clear which characters have been successfully transmitted by underlining those that are still finding their way through the tubes... i've never been unsure what has or has not been received.

      After a few days of using mosh, I don't see myself going back to plain old ssh anytime soon.

  3. Re:UDP for a connection which has to -reliably- se by ZorinLynx · · Score: 4, Insightful

    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.

  4. OCB Mode is Toxic. by TechyImmigrant · · Score: 4, Interesting

    We tried to put OCB mode in 802.11i. So IBM sent a guy to explain the 'licensing terms' for their patents on OCB mode. The next vote in 802.11i after that presentation was to replace OCB mode with CCM.

    Until the patents expire or are freely licensed, OCB mode should be considered off limits for free and open projects.

    --
    I should use this sig to advertise my book ISBN-13 : 978-1501515132.
    1. Re:OCB Mode is Toxic. by mikechant · · Score: 5, Informative

      The patents are freely licensed for any GPL software; see link for details.
      http://www.cs.ucdavis.edu/~rogaway/ocb/offer.htm

      Mosh appears to be GPL:
      https://github.com/keithw/mosh/blob/master/COPYING

  5. Other improvements ? by redelm · · Score: 5, Interesting

    IP roaming looks nice & ought to be secure with the right steps (no reply from old IP:port, correct cryto negotiation with new IP:port).

    But LOCAL ECHO is a big problem -- applications have to be aware of it. On CLI, many keystrokes are commands, not text to be entered. On vi in command-mode, G goes to the last line.

    Personally, a bigger thing is traffic reduction, particularly keystoke combining. Nagel's algorithm is a start, but I've modded ssh to delay and buffer likely-text keystrokes for a short time (400ms) while letting likely commands through immediately to retain responsiveness. The delays aren't irksome, and I reduce outbound traffic by ~80%.

  6. Re:Why would I want this compatibility break? by Hes+Nikke · · Score: 4, Insightful

    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.

    --
    Don't call me back. Give me a call back. Bye. So yeah. But bye our, well, but alright we are on a shirt this chill.
  7. Firewalls by Alarash · · Score: 5, Insightful
    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.

  8. Re:Missed from summary by vlm · · Score: 3, Interesting

    i can't see any idle traffic ... being specified

    I looked into MOSH in detail a little while ago and the keepalive packet is every 3 seconds or 3 packets per second can't remember which.

    It was often enough to make me pause... that's a lot of traffic if you're metered and paying by the K and/or powered by battery...

    --
    "Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
  9. Re:Obsolete within five years by silanea · · Score: 3, Insightful

    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.

    --
    Rudolf Hess edited Mein Kampf. He was the very first grammar nazi.
  10. Maybe not so good with completion by Anonymous Coward · · Score: 3, Insightful

    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.