* 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
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.
(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.
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.
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.
* Use a non-standard ssh port
* Disable root ssh login
* Configure 'Single Packet Authorization and Port Knocking' --
* Have decent iptables rules. Use either fail2ban or denyhosts
with stringent rules, if you must, that ban on 3+ failed
* 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:
* 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.
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...
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.
> * 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. :)
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.
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?
p.s. using a password with keys is two factor
> Mosh doesn't listen on network ports or authenticate users. The mosh client logs in to the server via SSH
> 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. :)
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.
But yes, it can't help with the initial connection, which has to be bootstrapped over ssh.
# Multiplex connections if there is more than one
* 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]?)
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)
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. :-)
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!
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.
> Includes its own private crypto code (has
rijndael-alg-fst.cc been vetted for timing issues?)
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?
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).
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.
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.
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."
I encourage people to uninstall mosh
on Ubuntu, sudo apt-get autoremove mosh
on Mac with MacPort, sudo port uninstall mosh
Since it uses ssh for authentication, it has eliminated some of its peer-review problems.
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.
Exactly - I don't understand what Mosh provides that GNU Screen doesn't... what problem is it actually solving?
EDIT: Fair enough, I stand corrected. :-)
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).
For nearby connections, it's no big deal, but cross-continent or overseas it's a right pain.
Has alleviated my laggy typing issues almost completely.
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.
 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.
Also think: when your webserver goes down while you're on holiday in Asia, character delay is salt in the wound.
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.
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
Using ^W can alleviate this.
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.
Also note that it doesn’t support IPv6 (there is a quick & dirty working patch in the github issue for that).
The "cygwin bash shell" which uses cmd.exe does the first test correctly but similarly fails on the others.
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?
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.
http://cl.ly/423P2B0u212B0k3j0g0X vs http://cl.ly/0M3f0o2c0O243v3z1N0W
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.
edit: github-issue: https://github.com/keithw/mosh/issues/103
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...
We're tracking this issue at https://github.com/keithw/mosh/issues/53
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.
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.
For actual text editing, it could just drop you into something like ConnectBot or Terminal.
Can't locate IO/Pty.pm in @INC (@INC contains:
/opt/local/lib/perl5/vendor_perl .) at /usr/bin/mosh line 24.
BEGIN failed--compilation aborted at /usr/bin/mosh line 24.
Anyway, that did the trick for me.
Would imply it does work well.
Datagrams are encrypted and authenticated using
AES-128 in OCB mode.
What happens if I tunnel my Mosh connection through SSH? Will I still get all the features (except for roaming, obviously)?
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.
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
dyld: Library not loaded: /Users/keithwinstein/homebrew/lib/libprotobuf.7.dylib
Referenced from: /usr/bin/mosh-client
Reason: image not found
Very excited to try this though!
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.
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.
And yes, having an Android client would be super sweet.
I really hope this becomes popular.
* X11 forwarding
* IPv6-only hosts or networks
* Android client
/usr/bin/mosh: Did not find mosh server startup message.
<it then disconnects>
Server runs FreeBSD and the client is OS X. Any ideas?
MOSH CONNECT 60001 cPiSdaPVTjKA/JQjy5jExg
mosh-server (mosh 1.1.3)
Copyright 2012 Keith Winstein <email@example.com>
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 188.8.131.52 60001
<it now starts connecting, but server side complains "Crypto exception: Packet failed integrity check.">
Anyway, doing network-resilient X11 is a harder problem than just ttys.