With the following setup, you won't need any wrapper for invoking screen
. Moreover, it avoids using /tmp
(with the consequent security risks).
Ensure you have an ~/tmp directory:
mkdir ~/tmp
Add to .screenrc
the following line:
setenv SSH_AUTH_SOCK "$HOME/tmp/ssh-agent-screen"
- This ensures that inside
screen
, ssh
looks for the socket always in the same location, rather than a changing path.
- You must use
setenv
whichever shell you use, since it's a screen and not a shell command.
Add to .bash_profile
the following line:
[ -n "$SSH_AUTH_SOCK" ] && [ "$SSH_AUTH_SOCK"!="$HOME/tmp/ssh-agent-screen" ] && ln -sf "$SSH_AUTH_SOCK" "$HOME/tmp/ssh-agent-screen"
- This will link from the fixed location (where
ssh
looks) to the real one, and must appear after starting ssh-agent
.
- Using
[ -n "$SSH_AUTH_SOCK" ]
will properly prevent errors when SSH_AUTH_SOCK
is not set.
[ "$SSH_AUTH_SOCK"!="$HOME/tmp/ssh-agent-screen" ]
will prevent screen sessions linking $HOME/tmp/ssh-agent-screen to itself, if screen sources .bash_profile
.
- Instead of starting
ssh-agent
in .bash_profile
, you can consider connecting with ssh -A
(to use agent forwarding and make the remote machine use your agent).
After this setup, you can just use standard screen command. You'll only need to recreate existing sessions or manually set SSH_AUTH_SOCK inside them to the fixed location of step 2.
Credits to this website for the idea; I avoided using /tmp
.
This answer is similar but uses extra aliases.
DISPLAY and AUTHORITY
An X program needs two pieces of information in order to connect to an X display. (Note that wmctrl
is an X program, even if it accesses other processes' windows rather than creating its own.)
It needs the address of the display, which is typically :0
when you're logged in locally or :10
, :11
, etc. when you're logged in remotely (but the number can change depending on how many X connections are active). The address of the display is normally indicated in the DISPLAY
environment variable.
It needs the password for the display. X display passwords are called magic cookies. Magic cookies are not specified directly: they are always stored in X authority files, which are a collection of records of the form “display :42
has cookie 123456
”. The X authority file is normally indicated in the XAUTHORITY
environment variable. If $XAUTHORITY
is not set, programs use ~/.Xauthority
.
Inside a screen session, the environment variables are determined when the session starts, unless you explicitly change them at some point. So if you start a screen session locally on your desktop machine, then attach to that session remotely, $DISPLAY
and $XAUTHORITY
are still pointing to your desktop machine. But if you start the screen session from an ssh connection from some machine C to your desktop machine, then the variables are not set. (They would be set to point to C if you had an X server on C and had enabled X forwarding over the ssh session.)
Getting the values of the variables
As far as I understand, you're trying to act on the windows that are displayed on your desktop. If you're the only person using your desktop machine, it's very likely that the display name is :0
. Finding the location of the X authority file is harder (under the default setup in Ubuntu, it's in a file with a randomly generated name).
Here are a few ways to obtain the values of DISPLAY
and XAUTHORITY
:
The easy solution is to always start a screen session from your desktop, perhaps automatically in your login scripts (from ~/.profile
; but do it only if logging in under X: test if DISPLAY
is set to a value beginning with :
(that should cover all the cases you're likely to encounter)). In ~/.profile
:
case $DISPLAY in
:*) screen -S local -d -m;;
esac
In the ssh session:
screen -d -r local
You could also save the values of DISPLAY
and XAUTHORITY
in a file and recall the values. In ~/.profile
:
case $DISPLAY in
:*) export | grep -E ' (DISPLAY|XAUTHORITY)=' >~/.local-display-coordinates.sh;;
esac
In the ssh session:
. ~/.local-display-coordinates.sh
screen
You could detect the values of DISPLAY
and XAUTHORITY
from a running process. This is harder to automate. You have to figure out the PID of a process that's connected to the display you want to work on, then get the environment variables from /proc/$pid/environ
(eval export $(</proc/$pid/environ tr \\0 \\n | grep -E '^(DISPLAY|XAUTHORITY)=')
¹).
Copying the cookies
Another approach (following a suggestion by Arrowmaster is to not try to obtain the value of $XAUTHORITY
in the ssh session, but instead to make the X session copy its cookies into ~/.Xauthority
. Since the cookies are generated each time you log in, it's not a problem if you keep stale values in ~/.Xauthority
.
There can be a security issue if your home directory is accessible over NFS or other network file system that allows remote administrators to view its contents. They'd still need to connect to your machine somehow, unless you've enabled X TCP connections (Debian has them off by default). So for most people, this either does not apply (no NFS) or is not a problem (no X TCP connections).
To copy cookies when you log into your desktop X session, add the following lines to ~/.xprofile
or ~/.profile
(or some other script that is read when you log in):
case :$DISPLAY:$XAUTHORITY in
:*:?*) XAUTHORITY=~/.Xauthority xauth merge "$XAUTHORITY";;
esac
Then inside screen you'll only have to setenv DISPLAY :0
(or whatever the display number is, but it's likely to be :0
as explained above).
¹ In principle this lacks proper quoting, but in this specific instance $DISPLAY
and $XAUTHORITY
won't contain any shell metacharacter.
Best Answer
It sounds like you are running the screen session on your laptop. Then sshing from that screen session to the remote host(s). Shutting down the laptop will kill the local screen process, which in turn kills the ssh session.
What you want to do is ssh from your laptop to the remote host(s). Then start a screen session on the remote host. When you laptop is turned off, the ssh session will die, but the remote screen session will persist.
The next time you log in to the remote system, you can re-attach to the screen session with "screen -r" or if you have multiple screen sessions "screen -r < pid >".
Note: if you forgot to detach from the remote screen session before ssh is killed, the screen session may think it is still attached. In this case, you'll need to do "screen -dr < pid >" to detach the session first.