Hacker News Reader

Comment by spindritf | Hacker News Reader

Or use mosh[1] on top of SSH and stop worrying about that stuff.

It works much better over high-latency links (mobile). It is not bothered by saturated links, tolerates IP changes and losing the underlying connection like when you suspend your laptop and take it elsewhere.

I now have mosh connect to several servers in tabs when I run gnome-terminal the first time, and only disconnect on reboot. I also run a mosh-capable Irssi Connectbot fork on the phone[2].

It's a massive improvement, fixing many of the little annoyances of ssh.

[1] http://mosh.mit.edu/

[2] http://dan.drown.org/android/mosh/

View on HN

The server I connect to most often is behind NAT and I'm usually also behind NAT, and mosh doesn't support that config, alas. I'd use it in a heartbeat if I could, though.

https://github.com/keithw/mosh/issues/48

I love mosh, but do note it's a lot slower than plain ssh. I run everything through a 266x188 tmux session, and mosh badly struggles to keep up even with light use. Resizing panes is juddery, vim is visibly laggy, and if anything spams a lot of output to a term (e.g. find /) it basically grinds to a halt. ssh is butter smooth in comparison.

No mouse support in mosh either.

(gnome-terminal/vte (so also Terminator, Xfce Terminal and others) is similarly slow, but as with mosh you don't really notice with smaller terms. I switched to urxvt).

Has anyone audited mosh's security model/encryption? Just curious since ssh is pretty tried and tested.

Authentication and initial key exchange is via ssh, so nothing to audit here. Afterwards data is sent AES-encrypted, which relatively simple.

> Afterwards data is sent AES-encrypted, which relatively simple.

It's simple to encrypt using AES, but that doesn't mean it is simple to encrypt in a secure way (i'm looking at you ECB mode). There are too many ways to accidentally mess up.

It uses ssh to set up the connection, so that setup is fine. The actual traffic is encrypted using AES-128-OCB, which is a great mode of operation.

I haven't digged too deeply into their security, but from what the main page says, it seems pretty trustworthy. Hopefully they're using the appropriate authenticated data, with packet numbers and so forth, to prevent silly things like replay and reordering attacks.

It might have faulty implementation for how it glues security features together, or encrypts the traffic data. I think the parent comment is talking about this kind of "audit" (i.e., not theoretically, but in action and by perusing the source code).

Yes, I addressed the "glue" thing with the note about authenticating the correct data (notably things like IVs and packet numbers).

But given that it uses ssh for the initial setup, I doubt there are any problems to be found with the initial key exchange, which is one of the trickiest parts of a "secure channel" protocol. And OCB, as an AEAD mode, is pretty hard to screw up, so long as (again) you make sure you're authenticating the proper data and generating IVs/nonces appropriately. Plus, they're using the (optimized) reference implementation for OCB, so that's probably pretty solid.

Now, I definitely agree that this isn't a proper security audit. But at a cursory glance, the general impression I get is that it's probably okay. Honestly, they've really removed most of the protocol complexity by using ssh to do all of the setup work.

It still lacks ssh agent forwarding.

…and performs scrollback very poorly.

I still use it, though. Can't wait for them to iron out these issues.

Reply on news.ycombinator.com