* 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.
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).
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.
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.
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.
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?
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.
* 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.
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.
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.
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...
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?
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!
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.
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.
> 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 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.
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.
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!
> 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).
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.
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.
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."
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.
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.
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.
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.
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.
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....
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.
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.
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 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.
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.
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.
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.
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.
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’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).
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)
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.
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.
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.
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.
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.
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.
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).
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.
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 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.
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.
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 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.)
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)?
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
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.
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.
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.
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).
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.
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?)
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
<it now starts connecting, but server side complains "Crypto exception: Packet failed integrity check.">
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.
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?
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?
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?
* 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