×
top 200 commentsshow all 378

[–]buffi 136 points137 points  (104 children)

I've tried this out a bit before when I've been on shitty wifi connections a lot, and I really like it.

I wish this would be more commonly deployed on servers in general, since it's really a huge step up from SSH in many ways.

[–]sprashoo 79 points80 points  (81 children)

Just set it up on one host with access to the servers, and then use tmux or screen to multiplex the ssh connections to any servers you need access to.

[–]Lucky75 31 points32 points  (4 children)

oh man, tmux is the shit. I can't live without it anymore

[–]Gaulven 8 points9 points  (3 children)

I used mosh, but I found that reattaching to existing sessions when the client has failed is annoying, even though not impossible. Sometimes term windows just get closed, or a laptop doesn't resume from suspend, so it happens.

What I've done instead is use autossh and tmux. I wrote a script for myself called autotmux (not related to anything by that name already existing). I give it the name of an ssh host and a session name, and it will maintain a connection to that tmux session on that host. The connection has these SSH options set:

ServerAliveInterval 15
ServerAliveCountMax 2

I use this script for terminal sessions that I need to be resilient and persistent. I definitely use it for production system maintenance.

I've meant to improve it to be a single script. As it is, there are two components.

autotmux

#!/bin/bash
#
# autotmux
#

# bash options
#set -o nounset # References to undefined variables will error
#set -o errexit # Commands returning with an error cause exit
#set -o noexec  # Dry-run
#set -o verbose # Verbose trace
#set -o xtrace  # Expanded command trace

# autossh options
#export AUTOSSH_FIRST_POLL=15
#export AUTOSSH_POLL=15
#export AUTOSSH_GATETIME=5
#export AUTOSSH_DEBUG=1
#export AUTOSSH_LOGFILE=$HOME/autossh.log
export AUTOSSH_PORT=0 # Disable autossh's keepalive mechanism, use ssh instead

# autotmux options
AUTOTMUX_SESSION_NAME='autossh'

# autotmux host defaults
AUTOTMUX_HOST=
AUTOTMUX_SOCKS_PORT=
AUTOTMUX_SESSION_NAME='autotmux'

BASENAME=$(basename $0)

# Helpful consistent print function
# usage: log message
log () {
    echo "[$(date +'%Y-%m-%d %H:%M:%S.%3N')] [$BASENAME:${FUNCNAME[1]}] $*"
}

print_usage () {
    echo "Usage: $BASENAME [host] [session-name]"
}

main () {
    # Check arguments
    if [ -z "$1" ]; then
        print_usage
        exit 1
    fi
    AUTOTMUX_HOST="$1"

    # Read host-specific configuration file
    CONFIG_FILE="$HOME/.autotmux/$1.conf"
    if [[ -f $CONFIG_FILE ]]; then
        log Reading host configuration from $CONFIG_FILE
        . $CONFIG_FILE
    else
        log Using defaults for host configuration
    fi

    # Name the tmux session
    if [ -z "$2" ]; then
        TMUX_SESSION_NAME=$AUTOTMUX_SESSION_NAME
    else
        TMUX_SESSION_NAME=$2
    fi

    # Set socks forwarding
    if [ -z "$AUTOTMUX_SOCKS_PORT" ]; then
        SSH_PORT_FORWARD=
    else
        PORT_BOUND_PID="$(lsof -i TCP:$AUTOTMUX_SOCKS_PORT -n -P -t)"
        if [ -z "$PORT_BOUND_PID" ]; then
            SSH_PORT_FORWARD="-D $AUTOTMUX_SOCKS_PORT"
            log Binding socks proxy to port $AUTOTMUX_SOCKS_PORT
        else
            log Port $AUTOTMUX_SOCKS_PORT already bound by pid:$PORT_BOUND_PID\; not passing option to ssh
            SSH_PORT_FORWARD=
        fi
    fi

    autossh -o "ServerAliveInterval 15" -o "ServerAliveCountMax 2" $SSH_PORT_FORWARD -t "$AUTOTMUX_HOST" '~/.autotmux/client.sh' $TMUX_SESSION_NAME
}

main "$@"

The following script exists on the client side.

~/.autotmux/client.sh

#!/bin/bash

if [[ -f $HOME/bin/tmux ]]; then
    CMD_TMUX=$HOME/bin/tmux
else
    CMD_TMUX=tmux
fi

if $CMD_TMUX has-session -t $1 &> /dev/null; then
    exec $CMD_TMUX attach -t $1
else
    exec $CMD_TMUX new-session -s "$1"
fi

I think the client-side script can be passed at connect time, but I wanted to post what I had since I mentioned I had something useful.

[–]inushi 12 points13 points  (1 child)

I used mosh, but I found that reattaching to existing sessions when the client has failed is annoying, even though not impossible. Sometimes term windows just get closed, or a laptop doesn't resume from suspend, so it happens.

Yes, if a mosh-client dies without cleanly shutting down the mosh-server, it is difficult to reattach to that mosh-server. And probably it should be difficult, because you won't want people to be able to hijack your sessions.

I run screen (or tmux), so I deal with orphaned mosh-servers by simply killing them. Then start a new mosh-client/mosh-server connection, and re-attach to my screen session.

[–]vbaspcppguy 26 points27 points  (66 children)

You make that sound easy.

Not really, it still sounds like a pain.

[–]JasonDJ 3 points4 points  (17 children)

It can be even easier...just setup mosh on one server and use it as a jump box. Though screen is pretty easy to use once you get used to it (15-30 minutes tops)

[–]galorin 13 points14 points  (15 children)

don't use screen. Spend the time learning screen to learn tmux instead. Then you can create a tmuxrc file that sets up your windows and connections as you want, each time you connect.

[–]AdShea 4 points5 points  (7 children)

Does tmux do serial consoles yet?

[–]campbellm 5 points6 points  (4 children)

http://dominik.honnef.co/posts/2010/10/why_you_should_try_tmux_instead_of_screen/

Missing Features

As mentioned earlier, there is in fact a feature missing in tmux: built-in serial and telnet support, while screen is able to directly connect to for example a serial null modem. Even more so, tmux will probably never include that feature, because the developer considers it bloat and says, that other, specialized tools should be used for that task instead.

[–]galorin 3 points4 points  (0 children)

No idea TBH. Never needed it.

[–]jaybusch 2 points3 points  (2 children)

Some servers at my university don't have tmux on them, sadly, so if I want to multiplex a session on them, I have to use screen.

Course, I could tmux on my own machine and go from there. Still a pain to have multiple logins on the same server instead of one login and multiple terminals.

[–]keltor2243 2 points3 points  (1 child)

Can you compile or upload code to your account? You can most likely run tmux from your own ~/bin depending on how they have things setup. A very long time ago, I had all of X installed under my account on a Solaris box because they wouldn't install it. I actually had "two" home directories because I had started sharing out the X install with other people. :)

[–]jaybusch 1 point2 points  (0 children)

I can compile and run code, we have access to gcc and cc from Solaris on that server. X is available, I think, but because there's only 20MB per account (last I knew, it was supposedly going to increase), no one wants to store a lot on there and it's not documented. It's just supposed to be for quick C file demonstrations + a small personal webpage.

I do want to compile and run tmux now, as I don't really like screen. The only other complaint I have about the server is it never liked it when I tried to make bash default. But I'm an idiot for config files for now, so I need to go back and fix something.

I'm gonna try X first and then compile tmux if that fails.

[–]JasonDJ 0 points1 point  (1 child)

Hmm I will have to look more into tmux then. I don't program or use Linux professionally but this sub has a lot of great info I can use. I am a networker and I have a Linux appliance in the office as a jump-box to my lab for when I'm working on customer networks or for building ssh tunnels to access guis. Also use Linux on a couple vms at home as part of my media center.

[–]vbaspcppguy 1 point2 points  (0 children)

I do love me some screen.

[–]sprashoo 15 points16 points  (43 children)

If you find that hard you perhaps shouldn't be the admin of multiple Linux servers... It's pretty elementary. Install tmux, install mosh, open port(s), connect to mosh, run tmux, ssh to server(s).

[–]vbaspcppguy 60 points61 points  (13 children)

Perhaps I shouldn't be, but I am. I really shouldn't be. But, I'm the best we have (two of us) and money does not allow to hire someone.

[–]thang1thang2 14 points15 points  (12 children)

There should be tutorials on how to do it. If you really have a desire to improve, I'd look into making a private wiki and storing all the tutorials you find on there (not just by pasting links, but by "writing" a how-to for yourself, so you teach yourself). In no time you'll find out that you're more than competent at the job. Linux is only hard if you don't have the time/desire to learn it.

[–]vbaspcppguy 1 point2 points  (8 children)

I've dabbled with Linux over the years but these three servers I just setup are my first into production... And they go to the data center tomorrow. I've gone through a dozen security walkthroughs and such. Feeling about as confident as I can be at this point.

[–]thang1thang2 5 points6 points  (0 children)

I wish you luck, then! First time servers are always nerve-wracking and you never feel like you set them up perfectly... I'm sure you'll do great, though.

[–]karlshea 3 points4 points  (6 children)

Everyone has to start somewhere. Mine was running a mail server on Linux and that sure taught me things pretty quick. A couple of years from now and you'll feel like a wizard.

[–]vbaspcppguy 1 point2 points  (5 children)

I had to do some with postfix, holy fuck what a mess.

[–]karlshea 1 point2 points  (0 children)

I switched to Postfix from qmail. 10x better if you can believe it. Now I just use Google.

[–]khoyo 1 point2 points  (3 children)

Wait till you meet sendmail...

[–]destraht 31 points32 points  (7 children)

I'm a software developer and I can do all of that stuff but it takes time and then I will only half remember it the next time and it just takes up precious mental space.

[–]Astrognome 5 points6 points  (4 children)

I've used tmux before, but I always have to have a cheat sheet.

[–]hardolaf 2 points3 points  (0 children)

I just use the built in help method

[–]kevrom 1 point2 points  (2 children)

I found tmux became way easier to use once I bound the prefix to Control-A and used vim's keybinds for navigation. Also, definitely do what /u/hardolaf said and use tmux's built-in help by pressing <prefix>-? and you can leave that by just pressing q

[–][deleted] 15 points16 points  (7 children)

Yeah that's a pain, I don't care who you are.

No one said 'hard', just 'pain'. Don't be a dick and perpetuate the egomaniacal IT helpdest L2 support guy stereotype.

[–]Kaelin 2 points3 points  (11 children)

I prefer mosh directly then tunneling through another server. I admin about 2k servers.

[–]fa2f 2 points3 points  (2 children)

admin about 2k server

seriously :O

[–]TheBranman 10 points11 points  (0 children)

Sounds like he should upgrade

[–]thang1thang2 1 point2 points  (6 children)

How do you admin 2k servers? I'm just curious what kind of job that is and I can't imagine what you'd actually use that many for...

[–]Kaelin 7 points8 points  (1 child)

Wireless telecom. Puppet and ansible

[–]saynay 2 points3 points  (0 children)

My guess, VMs, or hosts for VMs (like some PaaS shop). It would be pretty easy to have thousands of servers you administer, with most just being almost-identical copies of eachother.

[–]vt0r 2 points3 points  (2 children)

I just left a place where we had a small team of less than 10 guys managing over 3k servers. We managed mostly authentication-related things (and generic system configs) with Puppet on client machines, but we managed most to all of the setup on infrastructure hosts using Puppet for some and Chef for others. We were a web hosting provider that also provided cloud hosting, but every machine except maybe 50-100 were fully managed by us. The demand is hard to keep up with, but the support tickets were usually just simple configuration change requests on webservers, etc after the initial setup.

[–]arhuaco 3 points4 points  (2 children)

Screen user here. 'Get rid of network lag' sounds interesting. But it's weird to see an echo that might not actually be there.

[–]inushi 21 points22 points  (0 children)

Local echo is generally only visible when the connection lag is slow and you haven't yet received the server reply. The local-only characters are marked with an underline so you know those letters are different. (The underline is removed once the server reply confirms the characters.)

It works pretty smoothly when you actually encounter it.

[–]sprashoo 2 points3 points  (0 children)

You do catch mosh correcting itself from time to time if the network connection is poor...

[–]Mo3 2 points3 points  (10 children)

What stops you from deploying it yourself? Only takes like 2 minutes

[–]hbrel007 60 points61 points  (9 children)

Not every environment is loose like that.

[–]FozzTexx 34 points35 points  (9 children)

provides intelligent local echo and line editing of user keystrokes

Over on /r/RetroBattlestations we would call that "block mode" on our terminals. They've invented the IBM 3270 terminal emulator! You could also say "half duplex" but it's not quite correct although most terminal programs use half duplex as a synonym for local echo.

[–]TJKoury 21 points22 points  (6 children)

Yup, everything old is new again.

[–]oursland 29 points30 points  (5 children)

Sometimes re-inventions of old tech is exactly what we need now, but in a newer context. :)

[–]TJKoury 15 points16 points  (4 children)

Agreed! Everytime I hear someone reference 'the cloud' it makes me wonder what we will call the computers not immediately in front of us during the next iteration...

[–]jaybusch 6 points7 points  (1 child)

Slave machines designed to make it rain from the cloud.

[–]TJKoury 1 point2 points  (0 children)

That's....one way to put it.

[–]Headpuncher 3 points4 points  (0 children)

The cloud: mainframe over internet instead of intranet. In other words, mainframe without security.

[–]burkadurka 5 points6 points  (1 child)

most terminal programs use half duplex as a synonym for half duplex

[–]FozzTexx 2 points3 points  (0 children)

Oops. Fixed.

[–]dsprtd 407 points408 points  (35 children)

This masterpiece of software saved my job & family's living. I'm a web developer from Iran and my stupid gov limited access via SSH protocol to outside world for a while. Nearly all of my web servers are hosted in Canada, US and EU.

It's more like a miracle to me. Instead of repeatedly getting disconnected from servers and writing a bunch of unnecessary scripts to automating tasks (which is more like to controlling a mars rover: stressful and delayed!) I'm connecting to my servers simultaneously and stable.

I enjoying typing commands in real-time on my terminal. Thank you very much, Mosh authors. I owe you a life.

Edit: Maybe I exaggerated the situation a little. I know I could use VPNs but the total amount of work to bringing up a fully functional VPN is a big risk (they easily block popular VPN services) and I'm pessimistic to other free or paid services. According to my experience, occasionally we have some internet "blackouts" which they simply white-listing HTTP and UDP protocols, on this events only mosh will be survive.

[–]aclave1 51 points52 points  (0 children)

It's great to see how software can impact people in such profound ways. Thanks for your story!

[–]666666666 21 points22 points  (14 children)

get you a VPS from cloudatcost.com (on sale now for $35 for life, or $1/mo.) and set up sshd to run on port 80. Then just use ssh tunneling to get to everything else. Or set up openVPN on it. Or do whatever you want with it. :)

[–]dsprtd 20 points21 points  (1 child)

Thanks for your hint. Actually I was using it until last year but it seems they limited bandwidth for SSH tunnels/socks proxies too. Currently I'm using a custom made stunnel service plus tinyproxy to access web and my github/bitbucket repos. Also there is a great tool gohttptun which when nothing else giving me access to the free web, working like a charm.

[–]khoyo 9 points10 points  (0 children)

iodine is great too, I've never see somewhere DNS is banned... Except when the internet is really down, as it was in Egypt, etc, in 2011.

If you ever need it, FDN (a french ISP) set up an open RTC line when it happened. I'm not sur if it's still active, but you only need a modem to connect. The number is +33 1 72 89 01 50. (login: toto password: toto)

[–]therein 8 points9 points  (3 children)

They might be doing deep packet inspection and disallowing TLS, not by port, but by protocol signature.

[–]ggtsu_00 11 points12 points  (2 children)

The trick these days is to send https content, base64 encoded, encrypted and wrapped in a normal http packet.

[–]phoningitindustries 8 points9 points  (1 child)

Don't forget to rot13 it before sending!

[–]hostesstwinkie 20 points21 points  (0 children)

do it twice just in case.

[–]rox0r 9 points10 points  (3 children)

It seemed too good to be true, so i looked up reviews. Every review I found seemed to say how bad cloudatcost.com was. You might want to recommend using the monthly plan, since it doesn't look good.

[–]666666666 7 points8 points  (0 children)

meh, I've had no problems. But I haven't had it that long either. But it's just a dev box. I wouldn't use it for production anything.

edit: so I googled for reviews. The first one mentioned a couple of problems that I can attest have been resolved, and was overall good. I've submitted a ticket and got an answer in 24 hrs (well, it got kicked to level 2)

edit2: after looking at a pretty good number of reviews, they are all negative about the exact same things, during the exact same time frame. But every one of them basically say "For that price how could you go wrong?" And since the issues seem to have all been fixed I think this really is just a good deal, from a company that has a fairly long history of offering good deals. I might even upgrade my system now.

Edit 3: NOW they send me a coupon code that you can use to get 20% off (full disclosure, I get $5): vArYpAQeQA

[–]Wolfspaw 1 point2 points  (1 child)

Thanks for the hint. At $35 for life I just bought one, I'm sure I'll think on some usages for it >)

[–]666666666 1 point2 points  (0 children)

No joke ;) yvw

Check out sandstorm.io and pydio.io, you'll also probably want ssmtp

[–]rvXty11Tztl5vNSI7INb 6 points7 points  (17 children)

That's pretty amazing though I'm curious as to why you don't use local servers in Iran?

[–]dsprtd 21 points22 points  (15 children)

In some cases, specially when we need to provide HTTPS access or lower ping time, we have no choice but using local servers (currently HTTPS protocol access hosted outside of Iran is slowed down on purpose by them).

The big issue is the bandwidth price. It's nearly 5 to 10 times more expensive than similar quotation on global popular provider. For example one of my customers is paying equivalent of $120/m for 2TB quota on a low-end dedicated server.

[–]rvXty11Tztl5vNSI7INb 2 points3 points  (14 children)

Wow that is expensive. You think it is because of lack of supply or lack of demand?

[–]dsprtd 14 points15 points  (7 children)

Absolutely it's not lack of demands. Iran is among the top 25 countries with the most users.

I think it's caused by some shitty political-religious point of views from current oligarchy of Iran and then the greedy nature of Iranian telecommunication companies business models.

As an example I'm using a 2 Mbps link that costs me about 36000 Rls ~ $1.1 per GB.

[–][deleted] 4 points5 points  (1 child)

the greedy nature of Iranian telecommunication companies business models

[–]immibis 1 point2 points  (0 children)

the greedy nature of Iranian telecommunication companies business models

[–]immibis 1 point2 points  (1 child)

That's only about double the price here in New Zealand (where it's about $100/month for a 150GB/month plan, so 0.67NZD/GB = 0.56USD/GB). And we don't seem to have particularly corrupt telecommunications companies.

When you said it was horribly expensive, I was thinking of 20-100 times as expensive... not double.

[–]thang1thang2 8 points9 points  (4 children)

I'm not dsprtd, but he did say he was in Iran. I'm guessing this is less of a lack of supply/demand (there's definitely a demand), but rather the government attempting to control the internet in an overbearing way. Not quite as severe as, say, the China firewall or the North Korean "internet" but it's a very similar situation, I think.

[–]rvXty11Tztl5vNSI7INb 7 points8 points  (2 children)

Yes it could be but I tend not to trust western points of view on places like Iran though. Prefer to hear it from those with real life experience. As you can see from his reply it's actually to do with the cost of bandwidth.

[–][deleted] 1 point2 points  (0 children)

This is the kind of thinking we need more of in the world. Upvote this man.

[–]dekomote 78 points79 points  (18 children)

How is this a replacement for SSH when it uses SSH?

[–]xconde 124 points125 points  (12 children)

It gets "bootstrapped" by SSH but, after that, it is a different protocol.

I assume that if the project and demand grows they can always replace the SSH daemon with a mosh daemon.

Using SSH seems a good way to piggyback off its popularity so people can try mosh easliy.

[–]BCMM 87 points88 points  (3 children)

It's also a good way to let SSH do the authentication, because SSH supports several kinds of auth and almost certainly does them sensibly and securely.

[–]Nebu 25 points26 points  (0 children)

My understanding is that it when you run the client, it uses SSH to connect to the remote server, start the mosh-server, disconnect from the SSH session, and then use the mosh SSP protocol from thereon, thus not using SSH underneath.

[–]primitive_screwhead 26 points27 points  (17 children)

So for this to work, I have to open UDP ports 60000 to 61000 on my internet facing firewall?

[–]skush97 16 points17 points  (12 children)

No, only as many ports as the connections you need. I usually do about 5.

[–]molo1134 10 points11 points  (11 children)

But you need to account for zombie mosh-server instances as well.

[–]skush97 6 points7 points  (10 children)

I have a cron job to kill them, never ran into problems

[–]molo1134 4 points5 points  (7 children)

How do you differentiate active versus zombie processes?

[–]skush97 2 points3 points  (4 children)

I simply don't use mosh at 3 am when the cron job runs. And even if I did and my session got killed, it's less than 5 seconds to reopen.

[–]molo1134 17 points18 points  (3 children)

Well that kills one of the primary use cases. Having an always-on mobile roaming session. Laptop or phone. So I don't think that is a serious solution.

[–][deleted] 1 point2 points  (0 children)

This is definitely a good solution. The connection is killed for about five seconds at 3 AM. "Always-on" is not a constant requirement at all times.

[–]skush97 5 points6 points  (1 child)

It's true that it's not the best solution, but it's good enough for me. Just because it kills a connection at 3am doesn't mean that the whole purpose is defeated; for 23 hours, 59 minutes and 50 seconds per day I can work uninterrupted the 10 seconds of restarting mosh if I'm using it at the time is a small price to pay for an otherwise great program.

[–]molo1134 1 point2 points  (0 children)

I agree, its not perfect, but is workable for many use cases. Cheers.

[–]jajajajaj 1 point2 points  (0 children)

Well, no MORE problems, after that ...

[–]inushi 1 point2 points  (1 child)

Only if you expect to run 1000 mosh-server processes at once. Each running mosh-server will use one port, starting from the lower bound of the range.

[–]primitive_screwhead 5 points6 points  (0 children)

What I mean, is I don't want to open one. If its open on the firewall, then if mosh isn't listening on that port, then maybe some other process my malicious means or otherwise, could be. I have to police my ports, and listening servers, that much more rigorously. It's not an easy proposition to float in many environments.

[–]jceyes 21 points22 points  (7 children)

I havent really looked into it yet - but the support for intermittent connections immediately made me think mobile.

JuiceSSH apparently supports it https://play.google.com/store/apps/details?id=com.sonelli.juicessh

As does this ConnectBot-based project http://dan.drown.org/android/mosh/

[–]dutch_gecko 5 points6 points  (1 child)

I switched to JuiceSSH specifically to make use of mosh. It's an excellent client and mosh makes using SSH on a typically high-latency mobile connection a breeze.

[–]zan-xhipe 1 point2 points  (0 children)

I also switch to JuiceSSH for mosh, very useful when on a 6 hour bus trip through sparsely populated countryside with intermittent internet access, and work calls with a problem (I do the bus trip twice a month so that isn't an uncommon event)

[–]lluad 2 points3 points  (2 children)

There's support for it on iOS via iSSH - unfortunately iSSH is a bug-ridden pile.

[–]mb862 1 point2 points  (1 child)

I remember when I first got iSSH back in the day, worked great. Connecting to home machines, both OS X and Linux, to university and institutional networks, and even ACENET a couple times.

I haven't been able to make a successful outgoing connection since about 2012. Been using Prompt when I need to now, which has a nicer interface but not nearly the featureset.

[–]hstern 14 points15 points  (11 children)

Pity it doesn't have IPv6 support. It's kind of useless to me without it.

[–]JohnnieTalker 10 points11 points  (10 children)

It's work in progress. When it's finished you'll even be able to roam between IPv4 and IPv6.

[–]xuu0 5 points6 points  (0 children)

It has been stagnate for some time. The last stable release was over a year ago, and it has the same features as it did on its first release.

But despite that it works wonders and I use it daily to stay connected to my systems.

[–]hstern 13 points14 points  (8 children)

Sure, but who designs new software these days that doesn't work with V6 from the start? It's not difficult at all to code. V4 is the 2-digit date of our decade.

[–]pahakala 3 points4 points  (5 children)

It's not difficult at all to code.

sure, there are just many little things that you will probably get wrong

this is a good starting point on some reading material :) http://blog.powerdns.com/2014/05/21/a-surprising-discovery-on-converting-ipv6-addresses-we-no-longer-prefer-getaddrinfo/

[–]Taladar 5 points6 points  (4 children)

People who will probably get many things wrong (and don't use lots of tests, review,... to find them before release) are not the kind of people I want to code a piece of software that is essentially the gatekeeper to my servers.

[–]dmwit 2 points3 points  (3 children)

Technologies that are fiddly and easy to get wrong are not the technologies you want to be used in the gatekeeper to your servers.

Humans are humans, and our error rates are widely known and haven't changed in the decades we've been tracking them.

[–]Taladar 1 point2 points  (2 children)

Sadly that description also fits encryption which you definitely do want to use.

[–]crabsock 5 points6 points  (0 children)

Yup, nothing beats crypto when it comes to "fiddly and easy to get wrong", and you can throw in "hard to test" as well

[–][deleted] 23 points24 points  (36 children)

So do you need to install something like a mosh-server component in the server or it uses the existing ssh-server?

[–]brunnock 24 points25 points  (35 children)

Yes, you need to have Mosh running on both the server and the client.

[–][deleted] 106 points107 points  (31 children)

Then it looks like we will still be using ssh for the next 20 years.

[–]markild 30 points31 points  (7 children)

I would think of it more as a supplement for ssh than a replacement.

When using a low latency connection on a more or less stationary (address-wise) computer, there's not much of an advantage to drop conventional ssh.

High latency and mobile devices is where mosh really shines.

[–]kqr 9 points10 points  (6 children)

"Mobile devices" for me includes laptops, in this case. Being able to take my work computer home and everything stays connected is really nice. I mean, it's not a big deal because it would take like 4 seconds to connect again, but avoiding that mental burden entirely is worth much more than that.

[–]markild 4 points5 points  (0 children)

Unfortunate of me to use "mobile", I should probably have said "roaming" or something, but yes, a use case like that is very fitting.

[–]ztherion 3 points4 points  (0 children)

Also great if you're out and about and need to SSH on a shitty connection.

[–]Taladar 1 point2 points  (3 children)

Just put a screen or tmux reconnect into your shell init (.bash_profile or similar) on the server and use SSH public key auth. There is very little mental effort required to reconnect and you don't have to give some unreviewed random server component full access to your server. I highly doubt mosh is anywhere near as paranoid as SSH is.

[–]Detrie 26 points27 points  (21 children)

In the webpage it says

The server binary can even be installed in the user's home directory

They should implement a automatic installation feature, where during initial SSH connection the mosh-client would automatically install the mosh-server to the users home directory if it can't be found in the system

It would make switching from SSH to Mosh a lot easier.

[–]vividboarder 8 points9 points  (1 child)

I have written a shell script for automatically installing mosh in a home directory myself. Not automated, but simple. https://gist.github.com/11000123

[–]burito 2 points3 points  (1 child)

It would work for the simple identical OS to identical OS, but would blow up so easily for everything else.

The server is running a different Glibc from you? Splat.

The server is running on 32-bit and you're on 64bit? Splat.

The server is a different arch? Big splat.

The server is running Plan 9? Mac OS? Cygwin? Solaris?

It very quickly becomes a "don't even bother trying" type of problem.

[–]mcrbids 10 points11 points  (16 children)

If you have a server automatically installing anything, in particular anything that allows remote access, you have other problems.

[–]HighRelevancy 21 points22 points  (14 children)

All it would be is automation (from the mosh client) of SCPing (or similar) the server binary up and executing it. If you can install anything on the server, it can happen automatically. If you can't install anything on it... well, good luck making it do ANYTHING.

So I'm not quite sure what you think you're saying.

[–]mcrbids 1 point2 points  (1 child)

A read-only root combined with a no-exec home folder is a typical install for a medium-to-high security server environment. Such a server does exactly what it was deployed to do. It does nothing more, and nothing less. It's a server, you know? In this kind of environment, there is no automatic anything install. If you do it right, there's a staged release process that is both regular and certified (on similar hardware) prior to deployment. Nothing gets installed that isn't both certified and tested.

Pray tell, just what kind of server environment do you consider to be secure?

[–]phil_s_stein 2 points3 points  (11 children)

Automatic installation and execution is a vector for attack. I redirect the DNS query for the SCP address and can run anything I'd like on your machine. I take over the hosting server for mosh-server and I can run anything I'd like. &c.

[–]tmnt9001 3 points4 points  (3 children)

I redirect the DNS query for the SCP address and can run anything I'd like on your machine.

Can't you do that if he runs the commands manually anyway?

[–]sockmeistr 7 points8 points  (0 children)

Not quite the whole picture... The mosh server component is launched over ssh, and can be installed in your home directory if need be. Mosh delegates all the authentication work to the ssh session.

[–]BCMM 4 points5 points  (1 child)

Mosh does not have a daemon. An initial connection is made over SSH, and the server is started only when it is needed.

[–]oconnor663 2 points3 points  (0 children)

This is the important bit of context. There's no "mosh-server" package (that I know of). You just need "mosh" installed on both ends, and sshd running on the server.

[–]burkadurka 10 points11 points  (0 children)

I tend to use at least two wifi networks during the day (home, work, maybe a coffee shop). I very rarely turn my laptop off. Recently I went on a trip to another state. The mosh connection to my VPS in Japan is still open.

[–]hobbified 17 points18 points  (4 children)

Without IPv6, port forwarding, or X forwarding, it's not a replacement for SSH, just a complement.

[–]graycode 13 points14 points  (0 children)

I think it's meant to be a replacement for just the interactive terminal part of SSH, not the whole kitchen sink.

[–]Amndeep7 4 points5 points  (0 children)

Not yet supported, but on the roadmap
Forwarding of X11, SSH agent, etc.
IPv6, with roaming between v4 and v6
Android client

I think those features are in the works.

[–]dada_ 8 points9 points  (1 child)

What strikes me about Mosh is how strongly it underscores the fact that internet protocols are quite bad for unstable connections. Back in the day when some of the core infrastructure was developed (I wasn't around, but this is what I've heard), connections weren't particularly stable either, so it's a little surprising.

These days with mobile connections, we're having the same problems again. Mosh is a good example of how to deal with these situations.

[–][deleted] 2 points3 points  (0 children)

Back in the day when some of the core infrastructure was developed (I wasn't around, but this is what I've heard), connections weren't particularly stable either, so it's a little surprising.

Not true.

There used to be a protocol called X.25 which dealt with unstable connections. It sent each packet one hop at a time, each hop waiting for an acknowledgement before the packet could be forwarded to the next hop.

However IP came about with stable connections where the trunks were deemed so reliable that checksum checks were only necessary on the endpoints. That's why there's a header checksum in IP packets and a checksum in TCP packets.

So "the Internet" was built around the fundamental assumption of reliable networks.

Note that the reason why modern links are regarded as so reliable is because they often have their own check-and-retransmit mechanisms (Ethernet) or they transmit with an excess of forward error correction (radio).

[–][deleted]  (8 children)

[deleted]

    [–]pahakala 8 points9 points  (7 children)

    and that's why you should use mosh+screen

    [–]graycode 5 points6 points  (2 children)

    Of course, if you're using screen/tmux, then you don't really care if your SSH connection dies; you just reattach to the screen/tmux session in a new SSH session.

    [–]crabsock 4 points5 points  (0 children)

    Well, not having to do that is still nice, especially if you find yourself doing it over and over again due to network issues or something

    [–][deleted]  (2 children)

    [deleted]

      [–]Freeky 8 points9 points  (1 child)

      You just want to use the mouse's scroll wheel and instantly browse the output of that long running command

      Works out of the box with tmux if mouse-mode is enabled.

      [–]crabsock 2 points3 points  (0 children)

      one of the reasons tmux > screen

      [–]Xenian 15 points16 points  (0 children)

      A couple tips:

      • You must build master on both client and server if you want to use the mouse. There's a hack around this on the GH issue, but don't bother with it.
      • You should use tmux or screen if you ever use your scrollback. Mosh only synchronizes the current visible terminal state. So, if you background, say, vim, you won't be able to see any of your history.
      • If you lose mouse control, detach then reattach the session. Not sure if this is my issue, or generally though.

      I believe had some issue with mosh+screen, and chose tmux for that reason.. But that also gave me the incentive to give tmux a solid go after putting it off for years. Never going back.

      [–]LiraNuna 3 points4 points  (0 children)

      No SSH agent makes it impossible for me to use it: https://github.com/keithw/mosh/issues/120

      [–]Redditcycle 2 points3 points  (0 children)

      Here's how to use mosh to connect to a server and attach the server's tmux (note double --)

      mosh myserver -- tmux attach

      [–]BeatLeJuce 18 points19 points  (16 children)

      Interesting, I hadn't heard of this before! Looks promising, but I can't help but be sceptical when someone uses UDP for anything. Seems to me that you don't want to lose the packages that send my commands to the server, so you'll have to provide the consistency yourself afterwards, so they probably have to add a half-assed TCP implementation on top of UDP themselves again. At which point you might as well just modify the SSH-server to the point where it handles an interrupted TCP session gracefully to achieve the same thing.

      [–]markild 49 points50 points  (9 children)

      The whole reason why you would want mosh as opposed to an ssh-server is because they do "half-assed TCP".

      I have used mosh for quite a bit (mostly on a laptop connected with a high-latency/high-jitter connection), and the feedback loop is much tighter than what you would expect from regular ssh. By not doing TCP, the client never really lose connection, as there is no connection to speak of. The connection or session is simply indicated by the payload. Where you would usually time out on TCP and then have to reconnect, you would simply just continue sending data until you get the expected response.

      The main selling point, as a user, is the instant echo feedback. Mosh will output what you're sending locally, before it's actually confirmed received to the server (with visual cues telling you that this is not confirmed by the server). When the server has acknowledged the input, you will get visual cues telling you so.

      [–]tejp 14 points15 points  (8 children)

      The main selling point, as a user, is the instant echo feedback.

      The main selling point is better resilience against bad/unreliable connections. The echo feedback on a high latency connection is just one aspect of it. Another is that you won't get disconnected even if you have really high packet loss, lose internet access for a while or connect to a different network and get a different IP.

      When you are on a stable connection all of that is much less relevant and you also get better echo feedback from ssh.

      [–]thang1thang2 1 point2 points  (6 children)

      Know what the timeout for internet loss would be? I have super sketchy wifi sometimes at my University and I'm getting more and more interested in Mosh because of that

      [–]tejp 2 points3 points  (4 children)

      I don't think there is a timeout by default. The mosh server process just keeps running on the target machine and waits for the client to show up again. You can open a connection, hibernate your laptop and then wake it up again a week later in some different network and it will reconnect.

      Similarly the client will just try to reconnect until you manually abort it.

      [–]BCMM 5 points6 points  (0 children)

      They want different behaviour from what TCP provides. In a sense, they've rebuilt some of TCP's functionality on top of UDP, to provide things like guaranteed transmission without forcing them to use the bits of TCP they don't want.

      [–]anttirt 5 points6 points  (0 children)

      A custom reliability layer allows processing packets out-of-order which can really help with responsiveness, depending (naturally) on the domain and if you can classify some packets with less stringent reliability requirements (allowing out-of-order or lossy delivery).

      [–]terrorobe 4 points5 points  (0 children)

      At which point you might as well just modify the SSH-server to the point where it handles an interrupted TCP session gracefully to achieve the same thing.

      Mosh is not SSH and SSH is not Mosh.

      Mosh tries to solve the problem of unresponsive interactive sessions when dealing with unreliable networks.

      It implements terminal emulation combined with a reliable & secure transport while ignoring all the other shebang SSH comes with (file transfer, additional servers, channels, etc.).

      [–]boarhog 3 points4 points  (0 children)

      It's not really a replacement per se as it requires SSH to make the initial connection

      [–]wall_words 1 point2 points  (4 children)

      I've been using this for a while with great success. I only wish that iTerm2's tmux compatibility would work with Mosh =(

      [–]Xenian 1 point2 points  (3 children)

      What's the issue you're seeing? I've got that setup working fine over here.

      [–]packysauce 1 point2 points  (2 children)

      iTerm's tmux integration uses a special escape code that gets eaten by mosh. I'm curious as to what you have working fine. If you're using iTerm with tmux -CC over mosh without problem... then we need to talk :)

      [–]avapoet 1 point2 points  (0 children)

      Just compiled and installed on a server I maintain, then tested it out by walking up and down the stairwell at my office (which, being in a big stone building, intermittently exposes me to WiFi and to phone signal: sometimes both, sometimes one, sometimes neither) and it was wonderful. Thanks, OP!

      [–]RowYourUpboat 1 point2 points  (0 children)

      supports just one character set: UTF-8

      Hnnnnngggh. Yes.

      [–]F21Global 1 point2 points  (1 child)

      This is really cool! I hope development will pick up with the new publicity. Last commit on Github was 9 months.

      Can't wait for a release with IPv6 and SCP support!

      [–]d2biG 4 points5 points  (1 child)

      Seriously, this is news? I've been using it for 2 years...

      [–]nemec 2 points3 points  (0 children)

      I'm glad it's news. First time I heard about it.

      [–]seventhirteen 3 points4 points  (11 children)

      Laughing out loud at the AES-128 OCB for SSH replacement

      [–]ouaibe 2 points3 points  (4 children)

      I have no idea why they didn't use AES-256-GCM.

      Then again, I don't know how many people really take the time to carefully select decent cipher suites for SSH...

      [–]midgaze 1 point2 points  (0 children)

      Due to a weak key schedule specified in the standard for AES-256, AES-128 is probably harder to break than AES-256. Read this.

      [–]etaoinshrdlu_ 1 point2 points  (5 children)

      Care to explain why? (Just to make it clear, I'm asking because I'm interested in knowing more.)

      [–]ouaibe 1 point2 points  (0 children)

      OCB

      When considering the strength of the cryptography proposed by a product, not only is the key size (here 128bits) and algorithm (here AES) important, but the block chaining mode is also a critical aspect to take into account, because aside from other implementation/protocol problems use of a weak modes can lead to plaintext exposure, oracles, key extraction, etc.

      OpenSSH can make the use of other cipher suites that use different block chaining modes, such as GCM which has a better reputation than OCB, and use key size of 192 or 256 bits, more than the 128 bits proposed by mosh.

      There is no absolute demonstration that GCM is better than OCB, but there are documented attacks and OCB is less used widely and is patent encumbered (except for Open Source licenses).

      If OCB happens to be weaker than GCM it would mean that you could weaken the cryptographic strength of your OpenSSH installation by using mosh (which can be a consideration if you're using 256bits for the OpenSSH server and only 128bits for mosh).

      Disclaimer : I am not a cryptographer, you should hire one if you are developing security products.

      [–]seventhirteen 2 points3 points  (3 children)

      Not a problem!
      AES, or Advance Encryption System, is an old (1998) NIST encryption standard based on the Reijndael cipher.
      My strongest dislike for this standard is that it is the first open cipher approved by the National Security Agency (NSA) for top secret information. AES-128 was broken in 2010.

      In November 2010 Endre Bangerter, David Gullasch and Stephan Krenn published a paper which described a practical approach to a "near real time" recovery of secret keys from AES-128 without the need for either cipher text or plaintext. The approach also works on AES-128 implementations that use compression tables, such as OpenSSL.

      There has always been an open source contender to AES called Twofish, it has not been broken and the NSA is not recommending its use. Hell even AES-256 would be better than puny AES-128.

      Now the block cipher is not all there is to auth encryption.
      OCB in the context of the program means its using a Offset Codebook block cipher mode (which is good for authentication encryption all though there are collision attacks for this mode). This has to do with the initialization vectors used to start the algorithm (cipher).

      What is important about this IVs is that they should be done correctly to have large amounts of entropy and noise (randomness) for the result to be very difficult to reverse (reverse = crack). If you read the wikipedia article, there is an image where they show how selecting a bad mode can leave sensitive information to recover.

      This is a list of NIST proposed modes of operation. OCB is in there, not the best though. (I'd use GCM for performance and CCM for strongness)

      All in all, everytime I see a developer choosing AES-128 lets me know they don't care about good security practices or are trading security for performance (moot in this case for Twofish-256 is faster than AES-128)

      [–]Likely_not_Eric 2 points3 points  (0 children)

      I must point out that we don't have evidence that TwoFish hasn't been broken. Just that nothing is so far published.

      [–]etaoinshrdlu_ 1 point2 points  (1 child)

      Thank you very much, that was very informative :)

      I just checked what cipher is being used by default when I connect to my homeserver with SSH... Apperently it's AES-128-CTR o_O

      [–]geekguy 2 points3 points  (2 children)

      Pro Tip:

      Use screen when you have an intermittent connection.

      Screen is a virtual shell tool available on most Linux distributionsand is often installed by default.

      To start log into ssh.

      Start a named session.

      screen -S name_of_session

      If you are ever disconnected the screen process remains running add the current user.

      To reconnect to the session:

      screen -r -d name _ of _ session

      Enjoy!

      [–]FireReadyAim 4 points5 points  (0 children)

      Another good way to use ssh over an intermittent connection is with mosh, the thing this topic is about.

      [–]pozorvlak 4 points5 points  (0 children)

      Mosh is much better for handling intermittent connections - you can skip the disconnect/reconnect hassle entirely. And it makes laggy connections much less frustrating too. However, screen is still great for persistent connections, and there's no reason you can't use screen and mosh together - I use mosh and tmux every day to connect to a persistent IRC session from whatever machine I happen to be sitting at. Tmux keeps my session alive while I'm away from the machine, mosh means I barely notice any network flakiness.

      [–]moozaad 4 points5 points  (2 children)

      Doesn't replace ssh if it depends on ssh... it extends it or tunnels with it.

      [–]GTChessplayer 19 points20 points  (0 children)

      It actually just uses the SSH protocol for some initial rendez-vous. After that, SSH isn't involved.

      [–][deleted] 1 point2 points  (2 children)

      When this was first released I seem to remember that there was a lot of murmuring about the developers hand rolling their own encryption algorithms. Has that been resolved?

      [–]inushi 9 points10 points  (0 children)

      Mosh uses standard encryption algorithms, not hand-rolled. But the development team is smart enough to know that the context/usage of crypto is important, and mosh is using standard algorithms in a new context.

      From the FAQ:

      Mosh is actively used and has been read over by security-minded crypto nerds who think its design is reasonable, but any novel datagram protocol is going to have to prove itself, and SSP is no exception.

      [–]millstone 1 point2 points  (10 children)

      1. Type some lines
      2. Clear screen (cmd K on OS X Terminal)
      3. Type some more text

      The text in step 3 will appear in the wrong position, because mosh attempts to track the screen state, but didn't know you cleared the screen. This makes mosh unusable for someone who clears the screen a lot, which is a shame since otherwise it looks great.

      [–]cooper12 5 points6 points  (3 children)

      Have you tried using clear? I might be wrong, but cmd-K probably only clears the buffer locally.

      [–]jaybusch 1 point2 points  (0 children)

      That's what I was thinking. That's an OS X problem only, I think.

      [–]millstone 1 point2 points  (1 child)

      An example of my workflow: I am ssh'd into a remote machine, and decide I want to read a large text file with a graphical text editor. What I will do is:

      1. cmd-K to clear the screen and scrollback
      2. cat the file
      3. cmd-A + cmd-C to select all and copy it
      4. cmd-V to paste it into my text editor

      This is much quicker than futzing with scp. clear can't substitute in step 1, since it doesn't delete the scrollback. Unfortunately mosh doesn't support this; in fact with mosh there's apparently no scrollback at all!

      [–][deleted] 3 points4 points  (0 children)

      I always use CTRL+L (vertical tab) to get a "clear screen". Should work fine with mosh.

      [–]Freeky 2 points3 points  (2 children)

      Works fine here (urxvt, FreeBSD). Can you reproduce the problem with a different terminal emulator?

      [–]graycode 1 point2 points  (1 child)

      cmd-K? Why not ctrl-L?

      [–]reddit_user13 0 points1 point  (4 children)

      Native Win client??

      [–]prototrout 7 points8 points  (0 children)

      MobaXterm supports Mosh.

      [–]eminence 2 points3 points  (0 children)

      Mosh from the Chrome web store is a really good option for people on Windows (or on a Chromebook)

      https://chrome.google.com/webstore/detail/mosh/ooiklbnjmhbcgemelgfhaeaocllobloj?hl=en

      [–][deleted]  (1 child)

      [deleted]

        [–]mallardtheduck -1 points0 points  (19 children)

        available for GNU/Linux, FreeBSD, Solaris, Mac OS X, and Android.

        So it's only for *nix systems. To "replace" SSH, you'll need (at least) a client for every OS in vaguely common use.

        This:

        Mosh automatically roams as you move between Internet connections.

        Combined with this:

        Mosh doesn't [...] authenticate users. The mosh client logs in to the server via SSH, and users present the same credentials (e.g., password, public key) as before. Then Mosh runs the mosh-server remotely and connects to it over UDP.

        Sounds very difficult to secure. How do you ensure that the system connecting over UDP is the same system that ran the server over SSH?

        the connection resumes when network service comes back

        That's one of the primary use-cases for screen. One of the great things about screen is that you can start a session in any instance of screen and resume it from any other. e.g. start a session remotely, resume it locally, start a session in xterm, resume it from the console, etc.

        You don't need to be the superuser to install or run Mosh.

        Security hazard. May allow users whom aren't allowed interactive SSH to access an interactive session. Also, most (if not all) of the sets of installation instructions require root.

        sets the frame rate

        Why does it even have a "frame rate"? 99% of the time on the CLI, nothing is happening and there is no need to refresh the screen.

        With Mosh, the server and client both maintain a snapshot of the current screen state.

        So it's basically VNC for text-mode then? That may explain the "frame rate".

        The rest of these are criticisms of the comparisons between mosh and other terminal emulators, not the protocol/application itself.

        Only Mosh and the OS X Terminal correctly handle a Unicode combining character in the first column.

        Try running xterm with UTF-8 enabled (xterm +u8)...

        Only Mosh will never get stuck in hieroglyphs when a nasty program writes to the terminal.

        Well, if you only support one text encoding, it's kinda hard to get "stuck" in the "wrong" one...

        Only Mosh and GNOME Terminal have a defensible rendering when Unicode mixes with an ECMA-48/ANSI escape sequence.

        I'm not sure any response to a completely invalid thing to do is "defensible". Even OS X's terminal freezing is at least a somewhat valid interpretation of invalid data. (Of course, the reset menu option not fixing it is a bug.)

        [–]uid_zero 11 points12 points  (6 children)

        Mosh doesn't [...] authenticate users. The mosh client logs in to the server via SSH, and users present the same credentials (e.g., password, public key) as before. Then Mosh runs the mosh-server remotely and connects to it over UDP.

        Sounds very difficult to secure. How do you ensure that the system connecting over UDP is the same system that ran the server over SSH?

        From https://mosh.mit.edu/#techinfo:

        This is accomplished using a new protocol called the State Synchronization Protocol, for which Mosh is the first application. SSP runs over UDP, synchronizing the state of any object from one host to another. Datagrams are encrypted and authenticated using AES-128 in OCB mode. While SSP takes care of the networking protocol, it is the implementation of the object being synchronized that defines the ultimate semantics of the protocol.

        I like Mosh, but I don't use it on my public webservers. I limit access pretty strictly, which prevents Mosh from being useful. (SSH is only accepted from 2 IPs, only public key authentication is allowed.) It's neat, but I'm too paranoid to allow it to be used.

        [–]eminence 1 point2 points  (4 children)

        I like Mosh, but I don't use it on my public webservers. I limit access pretty strictly, which prevents Mosh from being useful. (SSH is only accepted from 2 IPs, only public key authentication is allowed.) It's neat, but I'm too paranoid to allow it to be used.

        If you are already restricting which IPs can SSH, why not similarly restrict which IPs can Mosh? Or are you worried about Mosh's ability to reject malicious spoofed packets (or something similar)?

        [–]OneOfTooMany 4 points5 points  (0 children)

        Sounds very difficult to secure. How do you ensure that the system connecting over UDP is the same system that ran the server over SSH?

        It doesn't have to be, but it needs to know the keys exchanged during the login over SSH.

        Security hazard. May allow users whom aren't allowed interactive SSH to access an interactive session. Also, most (if not all) of the sets of installation instructions require root.

        If you are not allowed to run interactive ssh session (no login shell), how would you run mosh process required to set up the connection? How is that different from providing any other binary that would provide shell? Unrelated to mosh.

        Source installation does not require root (if you provide correct path for configure script).

        Why does it even have a "frame rate"?

        UDP is not TCP, you decide when you send a datagram. Mosh does not send every key stroke (or a character on the screen) in a separate datagram, but it still needs to be interactive. So there is a "frame rate".

        [–]eresonance 2 points3 points  (10 children)

        That's one of the primary use-cases for screen.

        Bleh, screen is terrible compared to tmux, I would suggest anyone still using screen to move on to tmux and never look back.

        It should be noted, however, that something like mosh would also compensate for slow and/or spotty connections, which ssh/screen cannot do on it's own. That's where I see the major benefit here. It would help me a lot since remote connections to our office tend to be terrible.

        [–]JohnnieTalker 5 points6 points  (0 children)

        I also don't really understand the screen/tmux vs. mosh. I'm using tmux and mosh together. At home on my Mac I get all mosh benefits: No need for reconnect after a laptop standby or a change of IP address (e.g. when switching Ethernet to Wifi), predictive typing on slow mobile connections etc.

        And by using tmux I can still attach to my session when using PuTTY at work on my Windows machine. tmux also fixes the lack of a scrollback buffer in mosh, so ideally you want to combination of both.

        [–]tolos 3 points4 points  (3 children)

        Can you list any reasons why tmux might be preferred? I mostly use screen for simple multi-tasking (e.g., debug video card with links and vi) or to save a session on a remote machine. The only screen commands I use are create, detach and c-a c-".

        [–]eresonance 1 point2 points  (0 children)

        Tmux has a website: http://tmux.sourceforge.net/ and a list on their FAQ explains all the major differences: http://sourceforge.net/p/tmux/tmux-code/ci/master/tree/FAQ

        The major one for me was all the weird issues screen would have when you started customizing things in it. That and vertical splitting, I don't know how many years it took to get that fixed but I wasn't going to wait. I just got sick of trying to get it to do what I wanted and switched to tmux.

        From the tone of your post I'm assuming that you're skeptical that it would provide any benefit to you. It probably won't and if you're fine with how screen works then why bother switching? However when you want to do something a bit funkier or would like to make use of some of the newer features I would suggest you try it out. It can be configured to be very screen like except that it gets regular updates and the code isn't a disaster to maintain ;)

        [–]MertsA 1 point2 points  (0 children)

        Another awesome benefit is a good ssh like terminal for Android even on crappy mobile data.

        [–]scgtrp 4 points5 points  (3 children)

        Why do tmux fans insist on doing this every time screen is mentioned? Screen does exactly what I need it to; I see no reason to spend the time to learn a new thing that comes with no advantages I care about.

        [–]eresonance 1 point2 points  (2 children)

        Hey, if you want to use bash 2.0 and ancient versions of solaris all the more power to yah! It does the job and there's not a huge reason to update if you don't use all the fancy new features. Why would people want vertical screen splitting and maintainable code, pfft!

        However if you like doing anything even remotely more complicated than basic screen usage tmux is much less of a pain to deal with. And it can be configured quite easily to have the same keyboard shortcuts that screen uses so the transition for users is seemless. I would recommend you give it a try when you have some free time to screw around with it. It's quite nice :)

        [–]fani 0 points1 point  (0 children)

        Looks interesting. Will check it out.

        Supports keys as well so passwordless ssh or mosh should work as well.

        Lets see how it is

        [–]b10nik 0 points1 point  (0 children)

        I use this everyday and I'm loving it. It's great that mosh automatically "reconnects" when hopping networks.

        [–]remram 0 points1 point  (1 child)

        I've been using this everyday for a few years now, both on my laptops (Win 7, though cygwin, and OS X) and on my Android phone. Really reliable. I wish we had official support in irssiconnectbot though :-/