7

There seem to be many related questions but I'd like to see a specific workaround.

So, I used to be an avid iTerm2 user (irrelevant) and I started using tmux remotely because I want to avoid SSH timeouts, i.e. my main concern is that should a nuclear apocalypse destroy my laptop I can pick up on the remote server from where I left off.

Now I use it locally as well. Is there a way to cleanly mix the two things? I only see two options.

  • tmux on the local and on the remote machine (this is my current one). The sessions are completely independent, if my local one crashes the remote one will survive, etc.; unfortunately there can be no interaction, so I have to forget about preserving copy-paste history (correct me if I'm wrong) and similar things.
  • ssh from the local tmux and attach to a remote tmux. This way I'll have a remote tmux session inside a local tmux window, which seems extremely cumbersome to use on a daily basis.

So mainly the problem is that I want my cake and eat it too. I want to keep my work on the ssh connection (and multi-task within it whilst it's alive), but I also want to share my work between all my tmux panes, disregarding whether they're local or remote. Is it possible?

2
+100

My advice:

Use mosh to connect to the remote server, once the session starts, fire up tmux

mosh was built for the common, but less apocalyptic scenario of remote a session connecting through a cellular data link, before 3G was even a thing.

From the mosh man page:

mosh (mobile shell) is a remote terminal application that supports intermittent connectivity, allows roaming, and provides speculative local echo and line editing of user keystrokes.

Compared with ssh, mosh is more robust — its connections stay up across sleeps and changes in the client's IP address — and more responsive, because the protocol is tolerant of packet loss and the client can echo most keystrokes immediately, without waiting for a network round-trip.

mosh uses ssh to establish a connection to the remote host and authen‐ ticate with existing means (e.g., public-key authentication or a pass‐ word). mosh executes the unprivileged mosh-server helper program on the server, then closes the SSH connection and starts the mosh-client, which establishes a long-lived datagram connection over UDP.

Back in those days, if you used your laptop to log in to your ssh server, for example in a commuter train, using a CDMA "pc-card" modem on your blindingly fast compaq armada (omg pentium!), or using a serial cable to hook up that palm VII thingy that had some sort of data service; you would have your session disconnected every time you switched from one radio cell to the next, which in a commuter train could be every 3 to 5 minutes.

That would be an equivalent scenario to the old Soviet Union raining down plutonium along the train's track, from the connection's point of view...

so mosh to the rescue. It uses ssh to authenticate, but the rest of the session is handled by the mosh tunnel, which was specifically designed for session resilience on flaky links.

From a user's perspective, nowdays it's imperceptible. I still use it to ssh, er... mosh from my Android device using termux even though the links on 4G don't have this issue anymore.

Another frequent use case was ssh connections through flaky modem links over POTS, that would drop the session if your sister decided that she wanted to call her boyfriend and picked up the other FIXED phone in the house, even though you warned her that you'd be downloading U2's new album in MP3 format from a shady WaReZ site.

So if you would like to use this, install mosh using your distro's package manager on both server and client (no root needed on either, it will do a userland install if it can't get root, handy for Android devices) and then do:

terminus:~>> mosh trantor.mydoman.tld tmux
Last login: Wed Apr  4 21:27:38 2018 from XX.XXX.XXX.XXX
trantor:~>> 

Enjoy! =)

  • 1
    Not really what I was looking for, but if I don't award the bounty it goes to waste! Neither this or the answer from Timmy Browne really answered the question, so you get bounty as you have less reputation :) Thanks for the answer. – Simon D Apr 6 '18 at 2:00
  • Incidentally I haven't ever been able to get mosh to work - possibly NAT related as at github.com/mobile-shell/mosh/issues/623 – Simon D Apr 6 '18 at 2:23
  • Thank you! As I re-read your question I see I failed to abstract the requirement of reconnection with a different device if your session is interrupted. (Hand-off). My suggestion will get you there half-way or even 3/4 of the way to the solution, as mosh will persist a sessio even after sleep, or IP address changed (no trivial matter btw) however, shutdown or resuming the session from a different device is where this falls short, mainly because of encryption issues, but termux in the server will give the appearance of "hand-over" to the user, while te underlying sessions are different. – hlecuanda Apr 6 '18 at 3:19
  • Also, mosh is picky about its ports, as you mention. I've solved that issue by port forwarding ingress and egress erver-side on a single port UDP (60000 is a good standard choice ) and using the -p option when connecting, otherwise it will use a random port in the range 60000 to 61000 which is a huge attack surface to leave permanently open on a firewall. (It was a different time when mosh was conceived ) the final cli-fu would be mosh -p 60000 trantor.domain.tld tmux – hlecuanda Apr 6 '18 at 3:26
  • 1
    I think the problem I have with mosh is likely udp packets not forwarding across routers I don't control, but will need to investigate further. I opened the 60000-61000 range on client and server firewalls without luck. I'm not too worried about changing devices on the client side, but would prefer to keep connections when my device connects from different networks or when sleeping and rewaking. – Simon D Apr 6 '18 at 3:36
1

would sharing windows help?

tmux new-session -s shared "tmux new-window -n CoolName"
tmux link-window -s <src-window> -t <dst-window>
tmux link-window -s shared:CoolName -t $index#  (target is optional)
  • I don't think this works, as the local session won't be able to share with the remote session? Looks like github.com/tmux/tmux/issues/204 suggests this is not possible. github.com/yudai/sshh also has some functionality for duplicating ssh sessions across tmux panes, but that will not cover combining local and remote ssh sessions. tmate.io looks like a possibility. Thanks for the suggestion. – Simon D Apr 3 '18 at 15:39
0

There are some ideas at https://medium.freecodecamp.org/tmux-in-practice-local-and-nested-remote-tmux-sessions-4f7ba5db8795 for how to do this in tmux. Basically use a key to toggle access to the inner tmux.

The config that worked for me was the one at http://stahlke.org/dan/tmux-nested/:

unbind C-b
set -g prefix C-a

set -g status-bg colour40
setw -g window-status-current-bg colour40

bind -n C-t new-window -a
bind -n S-left  prev
bind -n S-right next
bind -n S-C-left  swap-window -t -1
bind -n S-C-right swap-window -t +1

bind -n M-F11 set -qg status-bg colour25
bind -n M-F12 set -qg status-bg colour40
bind -n S-up \
    send-keys M-F12 \; \
    set -qg status-bg colour25 \; \
    unbind -n S-left \; \
    unbind -n S-right \; \
    unbind -n S-C-left \; \
    unbind -n S-C-right \; \
    unbind -n C-t \; \
    set -qg prefix C-b
bind -n S-down \
    send-keys M-F11 \; \
    set -qg status-bg colour40 \; \
    bind -n S-left  prev \; \
    bind -n S-right next \; \
    bind -n S-C-left swap-window -t -1 \; \
    bind -n S-C-right swap-window -t +1 \; \
    bind -n C-t new-window -a -c "#{pane_current_path}" \; \
    set -qg prefix C-a

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.