How to automatically start tmux on SSH session?

SshTmux

Ssh Problem Overview


I have ten or so servers that I connect to with SSH on a regular basis. Each has an entry in my local computer's ~/.ssh/config file.

To avoid losing control of my running process when my Internet connection inevitably drops, I always work inside a tmux session. I would like a way to have tmux automatically connect every time an SSH connection is started, so I don't have to always type tmux attach || tmux new after I SSH in.

Unfortunately this isn't turning out to be as simple as I originally hoped.

  • I don't want to add any commands to the ~/.bashrc on the servers because I only want it for SSH sessions, not local sessions.
  • Adding tmux attach || tmux new to the ~/.ssh/rc on the servers simply results in the error not a terminal being thrown after connection, even when the RequestTTY force option is added to the line for that server in my local SSH config file.

Ssh Solutions


Solution 1 - Ssh

Server-side configuration:

To automatically start tmux on your remote server when ordinarily logging in via SSH (and only SSH), edit the ~/.bashrc of your user or root (or both) on the remote server accordingly:

if [[ -n "$PS1" ]] && [[ -z "$TMUX" ]] && [[ -n "$SSH_CONNECTION" ]]; then
  tmux attach-session -t ssh_tmux || tmux new-session -s ssh_tmux
fi

This command creates a tmux session called ssh_tmux if none exists, or reattaches to a already existing session with that name. In case your connection dropped or when you forgot a session weeks ago, every SSH login automatically brings you back to the tmux-ssh session you left behind.

Connect from your client:

Nothing special, just ssh user@hostname.

Solution 2 - Ssh

Alright, I found a mostly satisfactory solution. In my local ~/.bashrc, I wrote a function:

function ssh () {/usr/bin/ssh -t "$@" "tmux attach || tmux new";}

which basically overwrites the ssh terminal function to call the built-in ssh program with the given arguments, followed by "tmux attach || tmux new".

(The $@ denotes all arguments provided on the command line, so ssh -p 123 user@hostname will be expanded to ssh -t -p 123 user@hostname "tmux attach || tmux new")

(The -t argument is equivalent to RequestTTY Force and is necessary for the tmux command.)

Solution 3 - Ssh

Don't do this on the server-side!

(It is potentially dangerous because you can end up being locked-out of the remote machine). Instead, make use of ~/.ssh/config like so:

tmux 3.1 or newer¹ on the remote machine

Into your local ~/.ssh/config, put²:

Host myhost
  Hostname host
  User user
  RequestTTY yes 
  RemoteCommand tmux new -A -s foobar
  • As pointed out by @thiagowfx, this has the side effect of making it impossible to use, e.g. ssh myhost ls /tmp and should therefore not be used with Host * ... what I like to do is to have a Host myhost section with RemoteCommand tmux ... and then in addition to that I'll have a Host MYHOST section without it.
  • Instead of RequestTTY yes you could call ssh with the -t switch; thank you, @kyb.
  • Off-topic, but if you're dealing with non-ASCII characters, I'd recommend to change that into tmux -u … for explicitly enabling Unicode support even on machines that don't have the proper environment variables set.

tmux 3.0a or older on the remote machine

Almost the same as above, but change the last line to³:

  RemoteCommand tmux at -t foobar || tmux new -s foobar

¹ repology.org has a list of distros and their tmux versions

² new is short for new-session.

³ at is short for attach-session.


Only if, for some reason, you really, really can't do it client-side:

Using the remote's authorized_keys file

If you would rather not have an ~/.ssh/config file for whatever reason, or want the remote machine to force the connecting machine to connect to / open the session, add this to your remote ~/.ssh/authorized_keys:

command="tmux at -t foobar || tmux new -s foobar" pubkey user@client

This will, of course, work from all clients having the corresponding private key installed, which some might consider an upside –– but: should anything go wrong, it might not be possible to connect anymore without (semi-)physical access to the machine!

Solution 4 - Ssh

Connect:

ssh user@host -t "tmux new-session -s user || tmux attach-session -t user"

During session:

Use Ctrl+d to finish session (tmux window closes) or Ctrl+b d to temporary detach from session and connect to it again later.

> Remember! If your server restarted session lost!

When you are inside tmux anytime you can use Ctrl+b s to see sessions list and switch current to another.

Fix your .bashrc:

I recommend you to define universal function in your .bashrc:

function tmux-connect {
    TERM=xterm-256color ssh -p ${3:-22} $1@$2 -t "tmux new-session -s $1 || tmux attach-session -t $1"
}

It uses 22 port by default. Define your fast-connect aliases too:

alias office-server='tmux-connect $USER 192.168.1.123'
alias cloud-server='tmux-connect root my.remote.vps.server.com 49281'

Login without password:

And if you don't want to type password everytime than generate .ssh keys to login automatically:

ssh-keygen -t rsa
eval "$(ssh-agent -s)" && ssh-add ~/.ssh/id_rsa

Put your public key to the remote host:

ssh-copy-id -p <port> user@hostname

Additional tips:

If you want to use temporary session-id which corresponds with a local bash session use as tmux id:

SID=$USER-$BASHPID
ssh user@host -t "tmux new-session -s $SID || tmux attach-session -t $SID"

Solution 5 - Ssh

I used lines from @kingmeffisto (I'm not allowed to comment that answer) and I added an exit so terminating tmux also terminates the ssh connection. This however broke SFTP sessions so I had to check for $SSH_TTY instead of $SSH_CONNECTION.

EDIT 4/2018: Added test for interactive terminal via [[ $- =~ i ]] to allow tools like Ansible to work.

if [ -z "$TMUX" ] && [ -n "$SSH_TTY" ] && [[ $- =~ i ]]; then
    tmux attach-session -t ssh || tmux new-session -s ssh
    exit
fi

Solution 6 - Ssh

As described in this blog post you can ssh and then attach to an existing tmux session with a single command:

ssh hostname -t tmux attach -t 0

Solution 7 - Ssh

This is the one that actually creates a great user-experience. It automatically starts tmux whenever you open the terminal (both physically and ssh). You can start your work on one device, exit the terminal, and resume on the other one. If it detects someone already attached to the session it will create new session. Put it on the server, depending on your shell ~/.zshrc or ~/.bashrc.

 if [[ -z "$TMUX" ]] ;then
     ID="$( tmux ls | grep -vm1 attached | cut -d: -f1 )" # get the id of a deattached session
     if [[ -z "$ID" ]] ;then # if not available attach to a new one
         tmux new-session
     else
         tmux attach-session -t "$ID" # if available attach to it
     fi
fi

Solution 8 - Ssh

byobu is a nice useful wrapper for tmux/screen. Connects to an existing session if present or creates a new one.

I use it with autossh which gracefully reconnects the ssh session. Highly recommended in case of intermittent connectivity issues.

function ssh-tmux(){
  if ! command -v autossh &> /dev/null; then echo "Install autossh"; fi
  autossh -M 0 $* -t 'byobu || {echo "Install byobu-tmux on server..."} && bash'
}

Solution 9 - Ssh

You might find this useful - uses ssh in a loop and reconnects to or connects to an existing tmux session so you have a nice easy reliable way to reconnect after a network outage

#!/bin/bash
#
# reconnect to or spawn a new tmux session on the remote host via ssh.
# If the network connection is lost, ssh will reconnect after a small
# delay.
#

SSH_HOSTNAME=$1
TMUX_NAME=$2
PORT=$3

if [[ "$PORT" != "" ]]
then
    PORT="-p $PORT"
fi

if [ "$TMUX_NAME" = "" ]
then
    SSH_UNIQUE_ID_FILE="/tmp/.ssh-UNIQUE_ID.$LOGNAME"

    if [ -f $SSH_UNIQUE_ID_FILE ]
    then
        TMUX_NAME=`cat $SSH_UNIQUE_ID_FILE`
        TMUX_NAME=`expr $TMUX_NAME + $RANDOM % 100`
    else
        TMUX_NAME=`expr $RANDOM % 1024`
    fi

    echo $TMUX_NAME > $SSH_UNIQUE_ID_FILE

    TMUX_NAME="id$TMUX_NAME"
fi

echo Connecting to tmux $TMUX_NAME on hostname $SSH_HOSTNAME

SLEEP=0
while true; do

    ssh $PORT -o TCPKeepAlive=no -o ServerAliveInterval=15 -Y -X -C -t -o BatchMode=yes $SSH_HOSTNAME "tmux attach-session -t $TMUX_NAME || tmux -2 -u new-session -s $TMUX_NAME"
    SLEEP=10
    if [ $SLEEP -gt 0 ]
    then
        echo Reconnecting to session $TMUX_NAME on hostname $SSH_HOSTNAME in $SLEEP seconds
        sleep $SLEEP
    fi
done

Solution 10 - Ssh

I have the following solution that gives you two SSH hosts to connect to: one with tmux, one without:

# Common rule that 1) copies your tmux.conf 2) runs tmux on the remote host
Host *-tmux
    LocalCommand scp %d/.tmux.conf %r@%n:/home/%r/
    RemoteCommand tmux new -As %r
    RequestTTY yes
    PermitLocalCommand yes

# Just connect.
# Notice the asterisk: makes possible to re-use connection parameters
Host example.com*
    HostName example.com
    User login

# Connect with tmux
Host example.com-tmux
    HostKeyAlias dev.dignio.com

Solution 11 - Ssh

I know I'm reviving an old thread but I've done some work on the bashrc solution and I think it has some use:

#attach to the next available tmux session that's not currently occupied
if [[ -z "$TMUX" ]] && [ "SSH_CONNECTION" != "" ];
then
    for i in `seq 0 10`; do #max of 10 sessions - don't want an infinite loop until we know this works
            SESH=`tmux list-clients -t "$USER-$i-tmux" 2>/dev/null` #send errors to /dev/null - if the session doesn't exist it will throw an error, but we don't care
            if [ -z "$SESH" ] #if there's no clients currently connected to this session
            then
                tmux attach-session -t "$USER-$i-tmux" || tmux new-session -s "$USER-$i-tmux" #attach to it
                break #found one and using it, don't keep looping (this will actually run after tmux exits AFAICT)
            fi #otherwise, increment session counter and keep going
    done

fi

There's a cap at 10 (11) sessions for now - I didn't want to kill my server with an infinite loop in bashrc. It seems to work pretty reliably, other than the error of tmux failing on list-clients if the session doesn't exist.

Solution 12 - Ssh

Thie way allows you to reconnect to an old tmux instance if your ssh session drops. The exec saves a fork of course.

if [ -z "$TMUX"  ]; then
  pid=$(tmux ls | grep -vm1 "(attached)" | cut -d: -f1)
  if [ -z "$pid" ]; then
    tmux new -d -s $pid
  fi

  exec tmux attach -t $pid
fi

Solution 13 - Ssh

Append to bottom of your remote server's ~/.bashrc, (or possibly its /etc/.bashrc.shared (1)):

# ======================== PUT THIS LAST IN .BASHRC ==========================
# --- If we're run by SSH, then auto start `tmux` and possibly re-attach user.
#       $-         interactive only via current option flags
#       -z $TMUX   no tmux nesting
#       $SSH_TTY   SSH must be running, and in a shell
#
if [[ $- == *i* ]] && [[ -z "$TMUX" ]] && [[ -n "$SSH_TTY" ]];  then
  tmux attach-session -t "$USER"  || tmux new-session -s "$USER" && exit
fi

Many good tips above combined here, e.g. $- and $SSH_TTY are better I think.

And I like adding a few comments to help this old guy remember what's going on without having to look it up.

And finally, I like an exit at the end to cleanly come home when I'm done.

Thanks everyone.


Note I source a shared /etc/.bashrc.shared at the end of both user and root's .bashrc's, for common stuff used in both, like colorized ls, various aliases, functions and path extensions, i.e. I don't want redundant code in my root/.bashrc nor user/.bashrc.

Solution 14 - Ssh

This guys script works great. Just copy the bashrc-tmux file to ~/.bashrc-tmux and source it from ~/.bashrc right after the PS1 check section.

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestionAlex RyanView Question on Stackoverflow
Solution 1 - SshkingmeffistoView Answer on Stackoverflow
Solution 2 - SshAlex RyanView Answer on Stackoverflow
Solution 3 - SshSixtyfiveView Answer on Stackoverflow
Solution 4 - SshDenisKolodinView Answer on Stackoverflow
Solution 5 - SshmoneytooView Answer on Stackoverflow
Solution 6 - SshFabian PedregosaView Answer on Stackoverflow
Solution 7 - SshStanislaw BaranskiView Answer on Stackoverflow
Solution 8 - SshSandeepView Answer on Stackoverflow
Solution 9 - SshGoblinhackView Answer on Stackoverflow
Solution 10 - SshkolyptoView Answer on Stackoverflow
Solution 11 - SshBrydon GibsonView Answer on Stackoverflow
Solution 12 - SshericcurtinView Answer on Stackoverflow
Solution 13 - SshElliptical viewView Answer on Stackoverflow
Solution 14 - SshShōgun8View Answer on Stackoverflow