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 <vinc...@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;
