Mosh: SSH for 2012 | Hacker News Reader

Mosh: SSH for 2012

mosh.mit.edu

900 pointspc193 comments

Pretty cool, but some of its aims can be achieved in other safer ways:

* Use tmux, a multi-plexer, so you never lose the state of a program

* Use KiTTY as an SSH client- http://kitty.9bis.com/ - enable 'Reconnect' options

* Configure http tunnelling if you want, it's trivially easy to set up with either Chrome or Firefox

The end result: an SSH connection that's always alive when I need it to be. When I open up my laptop's lid, it reconnects automatically, and because I've set up keys (without a passphrase) I do not have to do _anything_ and I'm all good to go. You can have a tmux attach command coded and you really do not have to do a thing.

Some other notes: KiTTY is a PuTTY fork, with many new extremely delicious features (hyper links, better clipboard support, etc.)

To tunnel your http traffic (for when you're in a public spot and would opt for basic security):

Connection > SSH > Tunnels. Add a dynamic port... and concordantly configure proxy settings on your browser's end. For Firefox you don't need any extensions... for Chrome this extension, in my experiences, is fairly decent: http://switchy.samabox.com/ -- these directions will work for both PuTTY and KiTTY.

>> SSH waits for the server's reply before showing you your own typing. That can make for a lousy user interface. Mosh is different: it gives an instant response to typing, deleting, and line editing. It does this adaptively and works even in full-screen programs like emacs and vim.

If real-time text rendering is a must for you, consider TRAMP: http://www.gnu.org/software/tramp/

Also consider using EmacsClient: http://www.emacswiki.org/emacs/EmacsClient

And for vim, apparently there's netrw: http://www.vim.org/scripts/script.php?script_id=1075

keys without passphrase? i hope they do not connect to a publicly available server with other people's data on it.

If it's on OS X, keychains does a pretty good job of unlocking your (password secured) private key transparently. That's preferable to leaving your private key sitting around without a passphrase.

I knew someone would raise an issue there.

If you're that concerned about security, there are a handful of additional things you can do:

* Use a non-standard ssh port

* Disable root ssh login

* Configure 'Single Packet Authorization and Port Knocking' -- http://www.cipherdyne.org/fwknop/

* Have decent iptables rules. Use either fail2ban or denyhosts with stringent rules, if you must, that ban on 3+ failed logins.

* Have a whitelist of acceptable IP's for ssh access

* Use any system of 2-factor authentication. I'm partial to Google's Authenticator. Here're some directions to get that set up, if anyone is interested: http://guides.webbynode.com/articles/security/ubuntu-google-...

But seriously, if you have keys set up and someone manages to steal them... you've really got bigger things you should be focusing on.

No. Just No.

* Use a non-standard ssh port <= not security. plus i bet you're on 2222.

* Fail2ban: useless for key auth, you don't remote brute keys like that

* 2 factor: that is ok

If your comp can log directly without any authentication that is terrible practice. Your comp will eventually get compromised, stolen, etc and then its game over. The passphrase is no silver bullet but it helps a lot.

2 factor or tiny cryptokeys are best.

I definitely agree with much of what you've pointed out.

> * Use a non-standard ssh port <= not security. plus i bet you're on 2222.

Right, marginally better than using port 22, but it's still something (better than non-action, if you will). I do hope one takes the vigilance to set a port number sufficiently high up, and sufficiently random looking. I recall something about nmap, that it scans only up to 1023 by default or something.

> * Fail2ban: useless for key auth, you don't remote brute keys like that

Still set it up -- for http and other services.

> If your comp can log directly without any authentication that is terrible practice. Your comp will eventually get compromised, stolen, etc and then its game over. The passphrase is no silver bullet but it helps a lot.

I agree... I emphasized seamless logging in because that seems to be a big point that Mosh is apparently selling itself on. I do have stronger authentication methods set up for the production machine. :)

> I do hope one takes the vigilance to set a port number sufficiently high up, and sufficiently random looking

Hopefully not over port 1023. If a user gets on the system and crashes your ssh daemon through OOM killer or one of many other methods, that non-root user can then restart its own daemon and listen to that port that you put >1023 'for security reasons'.

Accidentally answering yes when it says a new key was detected is all it takes to get keylogged.

I don't see how you could answer yes to that prompt without realizing it was the 'key has changed' prompt. Especially when half the ssh clients I've seen abort entirely when the key changes.

The issue of using ports above 1024 is that unless you redirect it to <1024 through the kernel firewall, if the ssh daemon crashes, a local user can run a daemon and compromise your keys/passwords. If you trust all your users, it should be fine though, but still...

That's why the server has a private key, too, to identify itself to the user.

You can't rely on that if you have other users connecting though. Too many people ignore even the starkest of warning messages. While that problem will not go away, keeping SSH on a port below 1024 is slightly safer and has no disadvantage other than it isn't as catchy as 2222 (and if you are using 2222, be aware that automated attacks often check that as well as 22 because of how common an alternative it is, so you might as well just use 22 and be done with it).

Best not rely on any security once attackers have access to your physical system. Someone could even take your computer, install a keylogger, and get it back to you.

If you have a Mac and secure your SSH keys with Keychain someone could take it, crack it open, freeze your memory, and dump it.

Two factor is definitely the best you could do on this front but who sets up two factor with SSH?

it's simple with yubikeys

Tiny cryptokeys?

http://www.crypto-stick.org/ for example

No. Just No.

With a reaction to that I expected overwhelming technical objections to everything the parent said. Based on the actual contents of your objections, I think you would have been better starting it Yes! Additionally...

All the great-grandparent's points are true, but irrelevant. There are plenty of ways to improve SSH security. None of them make having passwordless keys anything other than utterly brain-damagedly stupid.

http://news.ycombinator.com/item?id=2236081

Think of it as security through irregularity instead of security through obscurity. You are not making your box secure by changing the ssh port, but you are decreasing the number of automated attempts that will hit your ssh port, which could, in theory, reduce your security risk.

but the original objection was regarding using passwordless keys. again, the main concern here isn't about automated attacks, it's about targeted attacks. someone got your key, it doesn't matter that you're running on a non-standard port. they'll figure that out, if they're targeting your machine specifically.

You realize you've effectively done the same thing as saving the password on the machine to auto-log-in with a password, right? The exception being it's harder to brute force the server (but you did mention server filtering, so forget that). They have ssh-agent for a reason.

p.s. using a password with keys is two factor

  * Use a non-standard ssh port

If someone has your private ssh key, then they presumably have access to your client-side ssh configuration. This might prevent random Internet attacks, but this doesn't do much against a targeted attack (which is what someone will do once they jack your private key).

  * Disable root ssh login

If your private key isn't authorized for root anyways, this doesn't really matter. This is just a point of general ssh security, not a protection against stolen private keys.

  * Configure 'Single Packet Authorization and Port Knocking' --
    http://www.cipherdyne.org/fwknop/

As with point 1, if someone is able to jack your private ssh key, they probably have enough access to view your ssh config.

  * Have decent iptables rules. Use either fail2ban or denyhosts
    with stringent rules, if you must, that ban on 3+ failed
    logins.

If someone steals your private key, then they won't have any failed login attempts. I'm unsure how you feel this makes using a password-less private key anymore secure.

  * Have a whitelist of acceptable IP's for ssh access

This presumably defeats the purpose of ssh mobility.

  * Use any system of 2-factor authentication. I'm partial to
    Google's Authenticator. Here're some directions to get that
    set up, if anyone is interested:

Using a password (something you know) + private key (something you have) already is two-factor authentication.

Instead of fake security solutions, how about using something like keychain (http://www.gentoo.org/doc/en/keychain-guide.xml)? Simply kill ssh-agent as part of the sleep event and you can have security and convenience. Trivial to implement and actually accomplishes something--unlike changing server settings in a scenario where I probably have access to your computer, which already knows how to login to your server!

That's definitely pretty workable. One big problem with these TCP-level approaches is you have to KNOW the connection is dead for roaming to work. So if you just walk and roam from one 802.11 ESSID to another, it won't necessarily just work until the TCP connection actually dies. Mosh roams right away (and warns you when it hasn't heard in a while) -- even if the client doesn't know it's roamed (e.g. because it's tethered to a NAT and it's the NAT that has roamed).

"* Use KiTTY as an SSH client- http://kitty.9bis.com/ - enable 'Reconnect' options"

Am I missing something, because the mosh site seems to indicate it works on most things except Windows and the KiTTY site seems to say it works only on Windows so they don't even serve the same set of potential users.

Try out autossh if you're not on Windows, and desire a persistent connection -- http://www.harding.motd.ca/autossh/

autossh is a program to start a copy of ssh and monitor it, restarting it as necessary should it die or stop passing traffic. The idea is from rstunnel (Reliable SSH Tunnel), but implemented in C.

Or just install cygwin and autossh. Works fine in windows. This plus Tmux works great.

Or you could, you know, just use Mosh.

I feel a bit guilty that my negative post is the top post, instead of a post discussing Mosh itself, most especially considering that Keith's responses throughout this thread have been quite elucidative and creditable. However I still think we should approach something as fundamental and important as remote access to our machines with great caution -- I'll be sticking with the tools tried and tested for years (and recommended by those I trust) for the foreseeable future.

That said, Mosh does seem pretty interesting, -- and by golly, considering the terrible 3G speeds I get on my Android phone and how often the 'connectbot' app acts up, I will surely be giving this a try when I get time later this week.

~~It all tunnels over SSH, what is the security risk compared to other protocols that also go over SSH?~~

(is it possible to strike text?) Thanks for the correction, I misunderstood how the protocol Mosh uses works. SSH is apparently used for initiation. Caution seems wise.

It's not all over SSH. It uses SSH to authenticate and start a server daemon, which it then connects to over UDP. The UDP connection is not tunneled through the SSH connection.

Thank you for this answer. I apparently missed this important distinction on my first pass through.

Except the nicest feature of Mosh is it makes the remote session feel more responsive. Is there anything out there (not just local echo) that does this?

What TRAMP, which is good, gives you is quite different to this.

> Mosh is a replacement for SSH. It's more robust and responsive,

> Mosh doesn't listen on network ports or authenticate users. The mosh client logs in to the server via SSH

Umm..

> Unlike SSH, mosh's UDP-based protocol handles packet loss gracefully

So it's not a replacement for SSH, but instead sits on top. Not only that, but it has some separate self-designed protocol that it uses to implement its ju-ju, presumably heavily peer reviewed for security design defects considering the claims of being an SSH replacement that are being made. :)

It's a replacement in the sense that, whenever you'd type 'ssh', you should type 'mosh' instead.

Exactly. It just happens to use ssh to bootstrap itself.

Yeah -- we use ssh to authenticate the user and log them in and start up the mosh server (an unprivileged helper process). Then we shut down the SSH connection and establish a direct (roaming) connection over UDP.

haskish :)

There are 101 million ways to screw these kinds of protocols up, that's why I'm sceptical. There are too many avenues to list, but here are a few:

* Security product written in C++, leveraging 2 huge libraries (Google protocolbuffers, Boost)

* One man band by the looks of it

* Includes its own private crypto code (has rijndael-alg-fst.cc been vetted for timing issues?)

* Implements its own private crypto protocol (has it been vetted for replay attacks? padding attacks? [insert 20 years of perplexing bugs confounding the greatest minds in computer science]?)

etc.

And besides all that, this page is begging you to download it. It ticks every box: sexy Bootstrap design, prepackaged installers for every OS, and not one mention of a single downside! That raises the question: what is the author's agenda? (At a guess, school cred, but still, this isn't reason enough for me to swap out something as critical as SSH)

We certainly welcome your eyes on the code. Any novel secure datagram protocol is going to have to prove itself; this one is no exception. Of course we think the radical simplicity of the design is an advantage, but of course others have thought that and have been wrong. So it's going to take time for everybody to get comfortable with it.

Regarding the Web site, I think Hacker News is able to take a little ribbing. You guys are always throwing up these twee Web sites; surely the free software community can have a little fun with the genre. :-)

From my limited perspective the code actually looks quite clean (although often this is the very quality that hides the worst of bugs!). One issue with UDP is dealing with NATs and firewalls (for example, in public WiFi hotspots where SSH is often permitted, but random other ports are not). The dependency on protocolbufs seems a little redundant given the size of your protocol (that is one huge library to import for the sake of 24 fields).

Will definitely give this a whirl at some stage, as the feature set is quite compelling, and assuming it gets healthy reviews from the talented crypto folk on HN. :) Good luck!

It’s good to be careful and perhaps a little skeptical when there’s a new approach that’s not the tried and true ssh.

The quote from the homepage tells me they get it:

Why you should trust Mosh with your remote terminal needs: we worry about details so obscure, even USENIX reviewers don't want to hear about them.

Agreed on the protocol buffers; that's a huge overkill for what it is used for.

    > Includes its own private crypto code (has 
      rijndael-alg-fst.cc been vetted for timing issues?)

This is as far as I can tell the original rijndael-alg-fst.c reference implementation, which has cache timing issues in the S-Box table lookup.

The crypto/aes/aes_x86core.c implementation from OpenSSL uses pre-fetching as a countermeasure.

[Edit: Better formulated as a question? :-)] Since OpenSSL is a long tested and optimized library, why did you decide to ship an own aes implementation?

We'll have to study this. The practical reason for using the rijndael reference code is that ocb.cc is only written against three interfaces: OpenSSL (which we can't ship currently for licensing reasons -- we depend on GPLed code), the rijndael reference implementation, and compiler AES intrinsics (which we don't have on most architectures).

Down the road we may end up making a shim to use GnuTLS or figuring out how to ship as GPL+OpenSSL exception.

The practical exposure to information leakage via timing attacks is pretty controlled, since we just ignore any datagram that fails the authenticity check and we generally only send outgoing packets per a timer (whose smallest value is 1/50 second).

OpenSSL also had 8 vulnerabilities in 2012 -- http://www.openssl.org/news/vulnerabilities.html.

Maybe this is the place to plug http://nacl.cr.yp.to/, by at least one author who has an excellent track record of shipping software with very few vulnerabilities. And who discovered the S-Box cache timing vulnerability mentioned upthread.

If you have the freedom to invent your own encrypted network protocol, instead of having to be backwards-compatible with SSL or SSH, you should seriously consider NaCl as an alternative.

Plus, in NaCl there's a work-in-progress implementation of CurveCP protocol http://curvecp.org/, which works over UDP and seem to be a good fit for something like mosh.

>Security product written in C++, leveraging 2 huge libraries (Google protocolbuffers, Boost)

Protocol buffers is heavily scrutinized and as for Boost, the way it's designed means that it only pulls in what you use. The project seem to only use very little of Boost anyway, so I wouldn't bother too much about it.

More surprising, I can see it does not use Boost.Asio for networking (strange ?). It seems to use Boost for things like Boost.Lambda (deprecated with C++11) and typeof.

I think the project could benefit from leveraging the Boost libraries more or just not use them at all.

Examples: use Boost.Spirit for Base64 and replace the custom made parser. Don't use malloc to allocate raw pointers but use strings, vectors or smart pointers. Replace the networking code with Boost.Asio (which is portable). etc.

That does not work. It seems to me that you need to install mosh server, which doesn't have much documentation at this moment.

I just installed the mosh client, and replacing ssh with mosh command alone doesn't work. By not working, I meant the error message is "/opt/local/bin/mosh: Did not find mosh server startup message."

Hint: you need to install mosh on both client and server. That error message means you have the client installed locally, but not remotely.

No kidding. Too bad they don't have good documentation on server installation (just client)

Keep down voting me as you like. The fact remains that Mosh is crap. If it works, it should just work. Otherwise, it is just crap.

I encourage people to uninstall mosh

on Ubuntu, sudo apt-get autoremove mosh

on Mac with MacPort, sudo port uninstall mosh

I'm downvoting you not because of your stance on Mosh, but because you're being, in the technical term: "A dick."

Generally speaking, I'll tend to downvote anyone who says something like "Go ahead and downvote me" unless the post is otherwise insightful enough to be worth an upvote.

I installed Mosh on both client and server and still got this message :-/

Well, same here. Obviously, the developer is on here trolling, down voting people for dissing their crappy project

Keep coming. I still have Karma you can down vote. It just shows how shitty this project is.

It uses ssh as the authentication and authorization channel to set up the socket on the remote machine. I don't want to make too many pronouncements as I haven't used it, but surely that's an example of being conservative with security behavior, not cavalier.

That said, I think the single biggest annoyance for me with ssh is the connection setup latencies (something like ... 9 round trips and a by-default-rdns-lookup I think?). This thing can only be worse in that respect.

Well, it helps in that you need to initiate a connection much less often. Once you have a connected mosh session, it will transparently roam with you, across suspend/resume or changing networks, as long as you like.

But yes, it can't help with the initial connection, which has to be bootstrapped over ssh.

Any time you are moving from one IP address to another, it better have some damn good security or else anyone will be able to hijack your session.

For some definition of "damn good" I guess. All security protocols can have holes. But a trivial session key is hardly rocket surgery. And spoofing attacks (which I assume is what you're talking about) don't require moving between one IP and another anyway.

If you are opening multiple ssh connections to the same host, you can add the following to your .ssh/config file

# Multiplex connections if there is more than one Host * ControlMaster auto ControlPath ~/.ssh/master-%r@%h:%p

It doesn't sound like it is tunneled within SSH --- rather, it uses SSH as a sign-in method to launch mosh's own protocol handler that uses its own socket. Once mosh launches, ssh exits.

Since it uses ssh for authentication, it has eliminated some of its peer-review problems.

Mosh works differently and at a different layer. With Mosh, the server and client both maintain a snapshot of the current screen state. The problem becomes one of state-synchronization: getting the client to the most recent server-side screen as efficiently as possible.

This is brilliant!

Combine that with the ability to rejoin your session and it's even more so -- only figures since the major use of screen was to enable this functionality over ssh.

> only figures since the major use of screen was to enable this functionality over ssh.

Exactly - I don't understand what Mosh provides that GNU Screen doesn't... what problem is it actually solving?

Packaging this functionality of screen with fewer manual steps with a protocol that provides a better experience over high latency connections.

Well, that and, this and screen are not mutually exclusive. I run a screen session inside my mosh all the time!

Persistent connections regardless of your connectivity. I just unplugged my laptop from ethernet and walked into the living room. When the wifi connected my mosh sessions continued where they left off.

with autossh and tmux i get exactly the same behaviour

This reminds me of Google Wave's operation transformation protocol except without the collaboration component [1]. Client edits are reflected instantly and client state is synchronized and reconciled with the server's.

[1] http://www.waveprotocol.org/whitepapers/operational-transfor...

Ok, I'll be "that guy". Why not just use tmux or screen? Is character delay a real issue in 2012? Seems like it's more of a proof of concept of their syncing algorithm rather than something super useful.

EDIT: Fair enough, I stand corrected. :-)

The killer app is not actually the predictive echo, but the improved handling of lossy networks and roaming between networks. On a crappy wifi hotspot that regularly craps out for a few seconds? mosh will notice and recover the instant it comes back, whereas ssh will have a delay or may not recover at all. Suspend your laptop with an active connection and come up an hour later on a different connection? mosh will instantly restablish connection like nothing happened.

I find character delay to be an ongoing frustration while using ssh with remote servers all day long. When I've mis-typed and need to backspace, I'm usually a couple of keystrokes ahead by the time I see it. I have to pause, wait, count, and carefully press backspace a precise number of times, and frequently get it wrong.

For nearby connections, it's no big deal, but cross-continent or overseas it's a right pain.

> a right pain

British English?

Read "a right pain" as "genuinely frustrating" or "really annoying".

Not sure why you got downvoted. Yes, that's definitely a more British construction.

I think he was downvoted for needlessly pointing out somebody's preferred flavour of English. Whilst it might not be your favourite, there's no need to make a bloody show of it ;)

I was merely curious. English is not my first language, I learned it at a pretty ripe age, so sometimes I miss some subtle nuances.

I'm actually reading the Harry Potter books (yeah, I know, but my kids are reading them too, and I figured I need to become an "insider" to that universe before they start making references that just go whoosh! over my head) and I remember seeing the expression "a right pain" somewhere in there.

Finally, I tend to be fascinated by odd and obscure language issues and details. I guess that's just the way I am.

Anyway, I'll be more careful to explain why I'm asking, in the future.

No, he was downvoted because people leapt to the conclusion that he was needlessly pointing out somebody's preferred flavor of English, when in fact he was a non-native English speaker (as a great many of HN participants are) who was curious about the origins of a particular turn of phrase.

Won't work for ncurses programs, but rlwrap ssh should help in most cases.

Works fine for ncurses programs, thanks.

Has alleviated my laggy typing issues almost completely.

I personally use it in conjunction with screen.

For me, it really shines when I'm on a crappy connection (like tethered through my phone or on terrible wifi), or when I suspend my laptop at home and wake it up at work -- the connection is instantly available.

I'm guessing you'd be surprised by the number of people that still suffer from typing latency issues. Not everything is <20ms away, sadly.

I remember with horror trying to maintain servers in Beijing from London a few years ago when the traffic took the "long way" around (most traffic routed via the US), giving me best case roundtrip latencies in the 250+ ms range or something like that.

I just have a terrible Internet connection so anything in the states (even my own server) is ~200ms.

not everybody lives in metropolitan America, and even then, not everyone who needs to do sysadmin has a reliable, wired connection 24/7. Character delay is an issue if you're on mobile broadband, which from the name, is the primary raison d'etre.

Also think: when your webserver goes down while you're on holiday in Asia, character delay is salt in the wound.

Character delay is absolutely a real issue over mobile network connections. I will occasionally try to get some work done on my laptop during a car or bus ride, tethered to my phone.

And while tmux/screen do keep the state server side, so you can reconnect, you have to do it manually. I usually connect to the wired network at my desk (to get lower latencies using Synergy), but may unplug my laptop to go to a meeting or debug an issue at another desk. Having to re-establish all of my connections when I do that is a pain.

And finally, tmux/screen do nothing about the UTF-8 incompatibility situation, and in fact may make it worse by adding an extra layer in between in which encoding information can be lost (I haven't played with this very extensively, but I have been frustrated in the past trying to get UTF-8 text entry to work over SSH).

Character delay is an issue over a sufficiently long distance network cable, forget mobile connections. Good thing I have tramp, and it doesn't ship it's own crypto....

In my case, I'm in the UK but my VPS across the Atlantic, so there's too much lag for comfortable typing and I make tons of typos.

How about Australia to France? That is what I am doing and I can feel the lag sometimes.

I do use screen for my servers, however when I go out of town[1] (our family cabin is in the north woods of Wisconsin, not exactly a 4g hotspot), getting a connection to drop, and having a variable 200-900ms ping while tethered to my phone makes working extremely difficult. Getting that dreaded "server down" text at 2am while on vacation is that much more painful.

[1] Or, for example, right now, where my home internet just went offline about 15 minutes ago and I'm tethered to my phone for connectivity.

I'm willing to go to considerable lengths to eliminate character delay - when the things I type don't show up on the screen instantly, it becomes harder to think in a painful way. That's an idiosyncratic reason, but it's there.

Yep, I think it's because the character delay forces you to simultaneously inhabit two levels of abstraction.

At the higher level, you're composing some tricky unix pipe, and at the lower level, you're counting many backspaces you've pressed and how far behind the echo is.

  % find . -name '*.txt' -mtime +2 -exec chmod g+w^H^H

> counting many backspaces you've pressed and how far behind the echo is

Using ^W can alleviate this.

And even better, just turn on Vi style line editing in your shell. Vi was designed for editing over high latency connections.

Did I miss the memo regarding the discovery of faster-than-light data transfers?

The Earth is a big enough place, with some of the connectivity achieved by means of geosynchronous satellite links. That adds a considerable delay, no matter what year it is.

c is a fundamental constant of the universe, and as such, is not subject to incremental improvement through Moore's Law.

I’ve been using this for a bit and it works pretty well most of the time (I especially like the prediction). On bad connections, I hadn’t have much luck with it (it timed out just like other TCP connections), but I only had a sample size of 1 ;).

Also note that it doesn’t support IPv6 (there is a quick & dirty working patch in the github issue for that).

Note to self: "brew install mosh" installs a scheme implementation. Install mobile-shell instead.

Is there any reason why Windows or at least Cygwin isn't supported? Much of the time, the whole point of SSH for me is to connect to a Unix machine from a non-Unix machine.

The code compiles under Cygwin with not too much effort -- the current master may compile. The big problem there is you don't really have a good UTF-8 terminal, but you're welcome to use it. If you know how we can best package the software for Windows or Cygwin users, we're happy to take a patch. (github.com/keithw/mosh.git)

Start with the putty source and integrate the mosh protocol?

Cygwin has a built-in utf-8 terminal that I find quite descent. (Only for some months, it did not have it before.)

Just posted some more terminal geekery on http://mosh.mit.edu -- I'd be interested how the Cygwin terminal does on the test cases shown there.

Those test cases look useful -- Do you know of any more sets?

I'm writing a terminal emulator out of interest, in hopefully a cross-platform way. I'm personally frustrated by the existing ones.

Got any wish-list items for one?

Mintty, badly. The first test gives no hat (or I just can't see it). The second causes it to get stuck in heiroglyphs. The third doesn't work correctly either. It looks like it prints xyz correctly, then jumps to the second line on screen and then continues from there.

The "cygwin bash shell" which uses cmd.exe does the first test correctly but similarly fails on the others.

mintty?

In case anyone’s interested, here’s how I managed to get Mosh to compile under Cygwin:

https://gist.github.com/gists/2349067/

Note (for keithwinstein?):

mosh doesn't handle iftop output properly. It may be that iftop abuses UTF8 or takes advantage of a bug to print certain characters, but it's not working right with mosh.

Thanks.

The quick fix is to run "LANG=C luit iftop" instead.

More detail: The problem is that we've made a design decision not to honor ISO 2022 locking escape sequences (which can be used as line-drawing characters), because they can end up sticking the terminal in permanent hieroglyphs and UTF-8 is supposed to be a stateless, self-synchronizing encoding. (See http://www.cl.cam.ac.uk/~mgk25/unicode.html#term for more detail than you probably want, or the examples I just added to mosh.mit.edu.)

We use the NCURSES_NO_UTF8_ACS=1 environment variable to request UTF-8 from ncurses instead of ISO 2022, and 99% of programs honor that -- but iftop is not one of them. It's within its rights, but I think these programs are rare enough that if you want to use the old-style line-drawing characters in mosh, it would be better to run just that program in luit (which is a translator), so that at least when luit exits, you'll be out of hieroglyphs for sure.

No go. "LANG=C luit iftop" in mosh or a normal shell is the same result as running iftop in mosh.

http://cl.ly/423P2B0u212B0k3j0g0X vs http://cl.ly/0M3f0o2c0O243v3z1N0W

What I find especially interesting is how they explicitly decided to design the site like a startup's. I always think it's cool when philanthropy learns from commercial enterprises.

It's just bootstrap [1], it's a laziness/cheapness/time constraint thing, not really mimicking.

[1]: http://twitter.github.com/bootstrap

Note that the screenshot has a listing of "ideas" for the site - including a note that says "Make it look like a fake startup company."

Honestly I'm actually getting really bored and annoyed with the amount of Twitter Bootstrap sites now, that don't change themselves at all.

If it was really about laziness, cheapness or time constraints, they would have just put up a Github README and would have been done.

Seems pretty clear they’re breaking with the crappy, poorly designed webpages open source software—especially anything having to do with networking or security—often have.

These guys understand: how something is presented matters too; not just how well the code works.

Am I blind or is there no way to connect to a custom ssh-port (other than 22) for the initial connection yet?

edit: github-issue: https://github.com/keithw/mosh/issues/103

I've browsed through the site and installed to look at the man page to find this out. I can't see a way to do this. Makes it useless for me :-(

Not that I'm complaining. It's not like I'm being asked to pay for it, just a feature that I imagine would be helpful to many people...

Thanks, we're working on it and it will be in a future release.

We're tracking this issue at https://github.com/keithw/mosh/issues/53

A workaround for this is to change the ssh default port in your ssh config file.

In .ssh/config:

    Host alias
        Hostname realname.domain
        Port alternate_port

I'll confess that I always run mosh with -a because it looks cooler when you see it predictively echoing text that you wouldn't otherwise get.

This looks really cool!

One question. I have a firewall (ufw) that is blocking most ports (I have a small whitelist). It looks like Mosh uses a UDP port between 60000 and 61000. Is there a way to pick a port for Mosh to use, or do I have to open that range of ports? It's not a huge deal either way, but it would be cool if I could tell it to use a specific port.

Oops. Nevermind. It looks like -p is what I want.

I wonder how easy it would be to hook this up to dns tunneling software such as http://code.kryo.se/iodine/ in such a way that after the the initial ssh auth step, you would have a useful terminal that would be accessible even behind captive portals and the like?

I've used mosh over iodine, by simply having the iodine-server forward all of my packets via IPv4 NAT. I then set my client gateway to use dns0 instead of eth0. Works great!

I'd like to see SSH optimised for touch-based user interfaces.

On mobile, we're stuck with crappy touch keyboards for at least the next few years (until serious haptic feedback or to some extent voice recognition becomes feasible).

I'm not even sure what it would look like. I just know that SSH right now is not a very pleasant experience.

In my imagination, it would be a touch-optimized way to issue commands. By checking your history file, the program could build a library of your most used commands. So maybe you tap a pleasantly large icon representing the server you want to connect to, it does the authentication for you, and then you get a pleasantly large list of your top 10 commands (scroll down for more). You click "apachectl", and then "restart" from the sublist that pops up. Add the "sudo" modifier and then tap a final pleasantly large button to issue the command.

For actual text editing, it could just drop you into something like ConnectBot or Terminal.

I'm having trouble imagining what role SSH or its replacement has in reinventing the text terminal for touch-based user interfaces. Seems like the whole idea would have to go out the window. VNC would work if the destination were also touch-based, but it's probably mouse-based, and I don't know at what level that's integrated into the protocol (probably too low).

http://acko.net/blog/on-termkit/

I've actually seen this before, and it is awesome, but it doesn't answer the question of how to re-imagine a text console for touch.

When I try to run mosh on my Mac (after installing from the .pkg provided) I get this error:

  Can't locate IO/Pty.pm in @INC (@INC contains:
  /opt/local/lib/perl5/site_perl/5.12.3/darwin-multi-2level
  /opt/local/lib/perl5/site_perl/5.12.3
  /opt/local/lib/perl5/vendor_perl/5.12.3/darwin-multi-2level
  /opt/local/lib/perl5/vendor_perl/5.12.3
  /opt/local/lib/perl5/5.12.3/darwin-multi-2level
  /opt/local/lib/perl5/5.12.3 /opt/local/lib/perl5/site_perl
  /opt/local/lib/perl5/vendor_perl .) at /usr/bin/mosh line 24.
  BEGIN failed--compilation aborted at /usr/bin/mosh line 24.

Is anyone else getting this error?

Never mind, the latest package (mosh-1.1.3-2.pkg) fixed it.

You're using MacPort's install of Perl, instead of the OSX's default. Edit the shebang in /usr/local/bin/mosh to point to /url/bin/perl.

Anyway, that did the trick for me.

I found this annoying too. It's not a core Perl module so it should be listed on requirements page. And really, do we need this complicated of a perl wrapper when they already wrote a C++ client?

How well does this work for something like vim? Line editing and mass transfer of commands is great if you're sending a long string, but if each keystroke is a command it seems like things would get stickier.

" It does this adaptively and works even in full-screen programs like emacs and vim"

Would imply it does work well.

It seems to work just fine. The local prediction looks kind of ugly with colorcolumn enabled, though, since it assumes characters are being inserted when doing local prediction, which shifts the colored column right for each keystroke until the update comes in from the server to fix it.

    Datagrams are encrypted and authenticated using
    AES-128 in OCB mode.

I'm curious to know more details. Does it leverage existing SSH auth infrastructure (ie. keys) for that, somehow?

Not exactly, no -- it's a new roaming secure datagram protocol. It uses SSH for the initial key _exchange_: if you run "mosh-server" by itself, you'll see it spit out a random 128-bit session key that protects the mosh session.

Is the protocol documented? I've looked at DTLS and I'm wondering how you prevent replay attacks and such.

It is documented in the research paper linked from the site, yeah. The big contribution with this protocol is that every authenticated datagram represents an idempotent operation on the recipient, so we don't have to worry about replay attacks as such.

I'm not sure how a terminal session can use only idempotent operations, but it sounds cool. I'll have to read the paper!

I'm scared to trust Mosh with my connection security, but the local echo sounds awesome.

What happens if I tunnel my Mosh connection through SSH? Will I still get all the features (except for roaming, obviously)?

Mosh sends its payload data through UDP, which you cannot tunnel through SSH.

No results for searching for "secur*" on that page. Are there any risks?

Try searching for "aes" and "ocb".

Ah thanks. Missed that in my cursory glance. I'm still curious as to the ramifications for sysadmins. SSH hardening guides have been around since forever. While this doesn't dramatically change things do you think it still needs some reliable advice on best use (static UDP ports etc)?

I also miss a discussion of how the protocol avoid denials of service once it's assumed that the UDP comes from any address -- if every packet from any address actually has to be decrypted.

Denial of service concerns seem to be at least briefly discussed in the paper (which I have not finished reading yet):

  2 We do not prevent against a denial-of-service attack where an ac-
  tive attacker intercepts packets and resends them under its own IP ad-
  dress to fool the server’s roaming detection. Such an attack would not
  compromise the confidentiality of the connection but would disrupt it.

(Not the same scenario as you are describing, but still.)

Does it have -R option like ssh, for port forwarding inside ssh session? Otherwise, I won't be able to connect to my work machines behind very strict firewall

Well shit. My VPS's glibc version does not have 64 bit byte-swapping functions, so I can't compile mosh for my platform. =( Can the authors update their requirements to list glibc 2.9 and perl IO::Pty module if they're compiling it themselves?

Edit: I hacked the swapping functions into mosh and built it, but my system lacks a UTF-8 locale, according to mosh (even after I copied an en_US.utf8 locale to the system). Not sure how to proceed

Mac OS X Lion: Mac OS X Lion

dyld: Library not loaded: /Users/keithwinstein/homebrew/lib/libprotobuf.7.dylib Referenced from: /usr/bin/mosh-client Reason: image not found

same error on OSX Lion. Also tried building from source and got: "No package 'protobuf' found"

Very excited to try this though!

Please try the new PKG (mosh-1.1.3-2.pkg) -- should be fixed. Thanks for your patience!

Thanks Keith

I've used mosh for about 10 days. It's worked perfectly for me. I disconnect/re-connect my laptop quite a bit between work/home/meeting rooms/hotels. My mosh sessions have lived through it all. I haven't had to restart or reconnect it once.

I'd send feedback directly to the mosh folks, but I have to subscribe to do so. A general thought for any project: please make it easy for folks to provide feedback.

For specific use cases this is an absolute lifesaver. I live a bit away from "normal" internet connections and will often go days without access to better than a weak GPRS signal. Being able to reliably issue commands without stabbing myself waiting for local echo/reinitiating the connection a dozen times/thinking about my AWS credit slipping away makes this something I would pay to use.

Note for Fedora users: this update was only pushed to stable yesterday[0] so you may not yet see it in your local package mirror.

[0]: https://admin.fedoraproject.org/updates/FEDORA-2012-5085/mos...

Is there a .src.rpm somewhere?

Assuming you are running the latest Fedora, you can get the SRPM from the main Fedora Project servers: http://dl.fedoraproject.org/pub/fedora/linux/updates/16/SRPM...

There are source and binary packages for Fedora 15, 16, the upcoming 17, and rawhide. You can configure your yum to use dl.fedoraproject.org instead of a choosing a mirror to get the latest updates, if you want.

Man, this could be perfect companion for screen and irssi. I wish there will be an Android client soon.

I set it up for that exact purpose. I'm using irssi on a remote server and it's annoying to reconnect every time I connect or disconnect from VPN. For now it works great.

And yes, having an Android client would be super sweet.

I really hope this becomes popular.

Not yet supported, but on the roadmap:

* X11 forwarding

* IPv6-only hosts or networks

* Android client

once it has IPv6 you can use it with iCloud and Back To My Mac.

Brilliant! Wish list: file transfer.

Seing as this already requires ssh, what's wrong with scp (I guess I'm assuming if you have ssh, you have scp, but I've never found that to not be the case).

Or even better: rsync tunneled over ssh.

Ability to resume. Actually, this would be awesome for file transfer because I could fire and forget and not have to worry about interruptions when I get off the train/my laptop goes to sleep or the battery runs out.

This looks fantastic and seems like a very much needed part of the ssh ecosystem. Most of my work is sshing from my home computer to servers in the cloud, and this seems like it will be perfect for mitigating the feeling of lag.

Nice homage in the terminal window (Mosh Web Site Ideas) to http://en.wikipedia.org/wiki/Important_Things_with_Demetri_M... :)

When connecting (for the first time) to a mosh server I get the following error message:

/usr/bin/mosh: Did not find mosh server startup message. <it then disconnects>

Server runs FreeBSD and the client is OS X. Any ideas?

Is mosh installed on the server? If you just normally ssh to the server and run "mosh-server", does it actually do something? (maybe it's not in your PATH?)

It's in my PATH. If I do that, this happens:

freebsd$ mosh-server

MOSH CONNECT 60001 cPiSdaPVTjKA/JQjy5jExg

mosh-server (mosh 1.1.3) Copyright 2012 Keith Winstein <mosh-devel@mit.edu> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law.

[mosh-server detached, pid = 2751]

Warning: termios IUTF8 flag not defined. Character-erase of multibyte character sequence probably does not work properly on this platform.

However back on the OS X desktop, if I do the following:

osx$ export MOSH_KEY=cPiSdaPVTjKA/JQjy5jExg

osx$ mosh-client 18.4.12.5 60001

I wish this used CurveCP.

ocb is patented... although the author claims it is "currently" free for gpl code. What are you guys thinking? At least only supporting one protocol is not that good.

I was very surprised at the use of OCB and not one of the other more widely-used authenticated encryption modes like EAX or GCM.

Intriguing, but I feel that most of the efficiency problems it tries to overcome can be mostly remedied by key-based SSH access. Can anyone comment on this?

It's solving a completely different problem. In fact it doesn't change SSH's authentication at all, so you'd still use your existing ssh key.

Ok so is the authentication pluggable (authorization I'm presuming is handled by pam and such)? Can I use Kerberos instead of SSH?

Do I understand correctly: to use mosh, I must have mosh-server available on the remote machine (?).

»Then Mosh runs the mosh-server remotely and connects to it over UDP«

i.e. yes

Shouldn't it be possible to install the mosh-server over the network from the client machine. Similar to what sshuttle does?

The documentation doesn't say this, but apparently, after you start mosh-server, it dies if there is no incoming request within 60 seconds. What is the point of the server if it is just going to quit after 60 seconds?

mosh-server is started up by mosh-client when it first SSH's in

Nice enough idea; but having protobuf and boost as deps is just silly for a system utility.

This actually sounds pretty sweet. I'm gonna try it on my vps! You get my upvote.

Ya...the features of Mosh sound quite interesting..there's been a lot of times when I forgot to quit out of my shell & had everything messed up...so had to relogin, etc. so this will certainly help. But one thing that I'm still not that sure about is the security...is mosh secure like ssh? It obviously acts as a client on top of that protocol if I'm not wrong then it should be pretty secure right?

No X11 kills the deal for me.

You can run X11 in a separate terminal?

Anyway, doing network-resilient X11 is a harder problem than just ttys.

Is it usable behind NAT/firewalls, as an alternative to a reverse tunnel?

related - Rocks: Reliable Sockets (unmaintained) http://pages.cs.wisc.edu/~zandy/rocks/

wasent Mosh the name of Powershell before it became PowerShell? Monad was the code name, MOSH (MOnad SHell) was a name for it too...

Reply on news.ycombinator.com