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

7 of 158 comments (clear)

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

  2. 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%.

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

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