Re: Logging off an X session closes all ssh -X connections started previously from outside X

[Vincent Lefevre <vincent@vinc17.net>]

On 2023-05-09 19:44:48 +0200, zithro wrote:
> On 09 May 2023 17:47, Vincent Lefevre wrote:
> > Hi,
> > 
> > On 2023-05-04 21:07:17 +0200, zithro wrote:
> > > Here is what happens chronologically :
> > > 
> > > 1. I start various SSH connections to a host, some normal, some with X
> > > forwarding, like that: "ssh user@host" and "ssh -X -n user@host GUI_APP"
> > > (like firejail firefox, firejail thunderbird, etc). There's no user
> > > connected under X yet, only the greeter is displayed.
> > > 
> > > 2. using VNC or rdesktop, I then log on to X on the machine, do some stuff,
> > > then hit "log off" from the desktop menu.
> > > Immediately, ALL the previous SSH connections started in step 1 get closed,
> > > hence all the shells and the GUI apps (firefox, etc) !
> > 
> > I have a similar setup (I also use lightdm and systemd) and do the
> > same kind of thing, but I haven't noticed any such issue.
> 
> Damn, now I wanna know the differences between our setups ^^
> Do you also have several DE installed (but not running concurrently) ?

No DE, just fvwm2.

> > BTW, you should also try GNU Screen to see if you have the same issue
> > with it (this could help debugging).
> 
> Do you mean trying "ssh u@h screen" ?

You need a terminal. Just do "ssh u@h" to start a remote shell.
Run "screen" from the remote shell. Detach the screen session.
You should be able to see the screen process (it should appear
as "SCREEN") with "ps -fwC screen". Then do an X login/logout.
I suppose that the ssh will terminate (as you described). Do a
"ssh u@h" again. And see if the screen process is still there
or if it has been killed at the logout.

If it has been killed, you may try again with:
1. ssh u@h
2. Start screen.
3. Detach the session.
4. Check with "ps -fwC screen" that screen is still running.
5. Log out from the ssh session.
6. ssh u@h
7. Check with "ps -fwC screen" whether screen is still running.

i.e. whether it has been killed at the ssh logout at step 5 (if
it has been killed, then I suppose that the issue is related to
any logout, not just X logout).

> As said in other posts, dunno how user lingering is configured on my setups.

loginctl user-status <username>

In my case, for the machine at my lab:

vlefevre (1000)
[...]
          Linger: no
[...]

On my VM, where I use lingering, I get:

vinc17 (1000)
[...]
          Linger: yes
[...]

> > I never use the -X ssh option, but I use X11 forwarding by default
> > (ForwardX11 yes), so I suppose that this is equivalent to -X.
> > 
> 
> No, AFAIK "ForwardX11 yes" is just to *allow* X11 forwarding, not to enable
> it on all ssh connections.
> Ie. running "ssh u@h GUI_APP" without "-X" does not provide the DISPLAY var,
> and so fails running GUI_APP with "Unable to init server: Could not connect:
> Connection refused".

I don't have any such issue. For instance,

zira:~> ssh cventin xterm
Connected to cventin (from 140.77.51.8)
OS: Debian GNU/Linux 12 (bookworm) [x86_64]
DISPLAY: localhost:11.0

and xterm is started as expected. FYI, some data, like DISPLAY, are
output by my .ssh/rc script (I've attached it and the associated
.ssh/xauth.wrapper Perl script too, in case this can be useful).

> Do you use "UsePAM yes" in sshd_config (server-side option only) ?

Yes (this is the default, and I haven't changed it).

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

# Vincent Lefevre's .ssh/rc file -*- sh -*-

# To avoid unexpected interaction with programs that send their data to
# stdout (e.g. svn when using the svn+ssh scheme), output every message
# to stderr. But be careful! When the -t option (pseudo-tty allocation),
# is used, stderr is redirected to stdout.

# The terminal name (pathname) is given by $SSH_TTY, as documented in
# the ssh(1) man page, and this doesn't depend on the shell that runs
# this script (the login shell of the user).

# Uncomment the following line to output $0 in order to know what pathname
# is used for this .ssh/rc script and can be tested by the .zshenv startup
# file via "$ZSH_EXECUTION_STRING".
#echo "Script: $0" >&2

case "$OSTYPE" in
  solaris*)  ip="$(echo $SSH_CONNECTION | sed 's/ .*//')";;
  *)         ip="${SSH_CONNECTION%% *}";;
esac

: ${HOST:=$(hostname)}
echo "Connected to $HOST (from $ip)${SSH_TTY:+ on $SSH_TTY}" >&2

if [ -r /etc/os-release ]; then
  . /etc/os-release
  echo "OS: $PRETTY_NAME [$(uname -m)]" >&2
fi

# In particular, the following will set the IUTF8 flag when needed.
# But we assume that the locale settings have been correctly passed.
# Code that fixes the locale settings (e.g. due to Debian bug 313317
# or https://bugzilla.mindrot.org/show_bug.cgi?id=1346 upstream bug)
# will need to rerun the following script.
if [ -n "$SSH_TTY" ] && [ -f $HOME/.stty ]; then
  alias stty="stty -F $SSH_TTY"
  . $HOME/.stty
fi

if [ -n "$DISPLAY" ]; then
  echo "DISPLAY: $DISPLAY" >&2
  if read proto cookie; then
    [ "$HOST" = prunille.vinc17.org ] && PATH=${PATH}:/usr/X11R6/bin
    if [ "$(echo "$DISPLAY" | cut -c1-10)" = 'localhost:' ]; then
      echo add "unix:$(echo "$DISPLAY" | cut -c11-)" "$proto" "$cookie"
    else
      echo add "$DISPLAY" "$proto" "$cookie"
    fi | $HOME/.ssh/xauth.wrapper -q -
  fi
fi

# $Id: rc 132022 2020-10-26 14:30:34Z vinc17/cventin $

#!/usr/bin/env perl

use strict;
use Fcntl qw(:DEFAULT :flock);

my ($proc) = '$Id: xauth.wrapper 43522 2011-05-04 02:17:18Z vinc17/xvii $'
  =~ /^.Id: (\S+) / or die;

my $authfile = $ENV{XAUTHORITY} || "$ENV{HOME}/.Xauthority";
open FILE, '+<', $authfile
  or die "$proc: can't open auth file '$authfile'\n$!";
my $timeout = 3;
while (! flock FILE, LOCK_EX | LOCK_NB)
  {
    $timeout-- or warn("$proc: timeout\n"), last;
    warn "$proc: waiting for lock to be released\n";
    sleep 1;
  }

exec 'xauth', @ARGV;