Remote server, iTerm2, and tmux integration

So, when you ssh into the server, you can use reverse tunneling so that you can talk back to your OSX machine to send it commands do pbcopy.

ssh -R 1234:localhost:22 remoteServer

Replace 1234 with any open port the remote server. Then on the remote server, you can then run:

tmux save-buffer - | ssh -p 1234 localhost pbcopy

That should connect back to OSX and send the contents of your tmux copy buffer to it. You may want to use ssh keys to prevent typing your password to your OSX machine.

If that works for, you can then create your tmux keybindings.

bind C-c run "tmux save-buffer - | ssh -p 1234 localhost pbcopy"

I should note, for this to work, you will need to turn on Remote Sharing in OSX.

Secondary Option:

Since you're using OSX, if you're also using iTerm2, you might consider installing http://code.google.com/p/iterm2/downloads/detail?name=tmux-for-iTerm2-20120203.tar.gz&can=2&q= on your servers.

It's basically a custom tmux what supports the "-C" flag. This flag hands over windows, and panes and all their splitting to iTerm2.

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! =)