Each time you ssh into bastion01
, a different socket is opened to handle the key forwarding. You can see the filename in the environment variable SSH_AUTH_SOCK
. When you start tmux
, the value of that environment variable is included in tmux
's global environment, which is inherited by any shells started in that session.
Now, when you reconnect to bastion01
later, a different socket is allocated to handle your key forwarding (since it's a new ssh session). You can see this by examining the value of SSH_AUTH_SOCK
before you re-attach to your tmux
session and after. In order for key forwarding to work inside tmux
, you need to update the value of SSH_AUTH_SOCK
inside tmux
to the name of the socket being used by the current ssh session.
A quick-and-dirty way to do this is to write a short script that will save this new value to a file, and execute that inside any tmux
window where you will be ssh
-ing from.
#!/bin/bash
echo "export SSH_AUTH_SOCK=$SSH_AUTH_SOCK" > ~/.auth_ssh
Execute that script as soon as you ssh into bastion01
, but before you re-attach to your tmux session. Then, before you try to ssh anywhere from inside tmux
, run the following:
source ~/.auth_ssh
Each tmux
window has its own environment, so you'll need to run that in each window where you try to run ssh. For simplicity, you can alias ssh to do it for you:
alias ssh="source ~/.auth_ssh; ssh"
Note: this is a gross oversimplification of a script we use at work to update the SSH authorization information. If it doesn't work quite right, I hope this at least gives you enough information to google a better solution (or someone else posts a better solution here).
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! =)
Best Answer
Not 100% sure it'll work for you, but that link didn't work for me either and I just copied the DISPLAY variable from the initial terminal and wrote
export DISPLAY=${copied from outside tmux}
which worked fine - i.e.the function from that link gave me a completely different DISPLAY which didn't work