Return to Answer

Added another approach to solve the current problem.

Source Link

edited Mar 21, 2020 at 14:39

UPDATE:

Yesterday I was thinking about this question for some reason, and came across a different approach which might work.

The idea basically consists in ditching the desktop/login managers instead in authenticating from them, and starting X by yourself remotely.

Say your SSH server service is enabled in your desktop. From a remote machine (your phone), stop the desktop manager (SDDM, for example):

# systemctl stop sddm

Now let us suppose you have some other X initialization package installed, like xinit, where a command like startx would suffice. If you were running from a console,

$ startx

would start X according to your configuration files without any problem. I don't know about every Unix-like system, but, from my experience, startx will look after $HOME/.xinitrc or, if the file is nonexistent, /etc/X11/xinitrc, and the X server will start as expected.

Unfortunately, we're not in console, and when trying to run from another shell like the terminal emulator where we're sending commands via SSH, simply sending

$ startx

retrieves

/usr/lib/Xorg.wrap: Only console users are allowed to run the X server

On the other hand, root can initialize the X server remotely from secure shell via a terminal emulator. For instance,

# startx

initializes the X server as expected, following the configuration files from root's home (or /etc/X11/xinitrc, as aforementioned). This makes us think it is about permissions, and not inability to do so.

After a couple minutes of searching, I've stumbled across Error when trying to use Xorg: Only console users are allowed to run the X server?, SSH login shows Only console users are allowed to run the X server, both of which boil down to the same path, edit (or add and edit, if nonexistent) /etc/X11/Xwrapper.config to include the following lines

allowed_users=anybody
needs_root_rights=yes

which indeed allows the startx command to be run by a regular user from the terminal emulator.

A note:

Please verify if your Xresources file is loading accordingly. Remember to correctly add to xinitrc your desktop environment, window manager, xrdb command, and so on.

Relevant:

I am also considering another approach inspired in How to remotely log in with full graphical desktop over X11 but need to think about it a little more. It may serve as inspiration for further solutions and possibly a better or more suitable option.

UPDATE:

Yesterday I was thinking about this question for some reason, and came across a different approach which might work.

The idea basically consists in ditching the desktop/login managers instead in authenticating from them, and starting X by yourself remotely.

Say your SSH server service is enabled in your desktop. From a remote machine (your phone), stop the desktop manager (SDDM, for example):

# systemctl stop sddm

Now let us suppose you have some other X initialization package installed, like xinit, where a command like startx would suffice. If you were running from a console,

$ startx

Unfortunately, we're not in console, and when trying to run from another shell like the terminal emulator where we're sending commands via SSH, simply sending

$ startx

retrieves

/usr/lib/Xorg.wrap: Only console users are allowed to run the X server

On the other hand, root can initialize the X server remotely from secure shell via a terminal emulator. For instance,

# startx

allowed_users=anybody
needs_root_rights=yes

which indeed allows the startx command to be run by a regular user from the terminal emulator.

A note:

Please verify if your Xresources file is loading accordingly. Remember to correctly add to xinitrc your desktop environment, window manager, xrdb command, and so on.

Relevant:

Source Link

answered Dec 21, 2019 at 15:21

a-sf-d

This question is probably related to:

Remotely start session on display :0 and Starting x11vnc remotely when X server is already running

For this answer, I will assume systemd as service manager, SDDM as desktop manager, and x11vnc as VNC server. For different resources, adaptation is not involved.

If you have booted your computer remotely, through wake-on-lan, for example, and have no physical access to your keyboard as to enter the user password on KDE's login screen, you will not be able to open the X display through SSH by simply starting a VNC session, such as

$ x11vnc --display $DISPLAY

The output of the command will be somehow verbose, but reading through it you will find something on the lines of

20/12/2019 19:32:35 *** XOpenDisplay failed ($DISPLAY) *** x11vnc was unable to open the X DISPLAY: "$DISPLAY", it cannot continue. ***

because there is no X-session authenticated yet.

If we read further through the output, we will find

** If NO ONE is logged into an X session yet, but there is a greeter 
login program like "gdm", "kdm", "xdm", or "dtlogin" running, you
will need to find and use the raw display manager MIT-MAGIC-COOKIE 
file. Some examples for various display managers:

gdm: -auth /var/gdm/:0.Xauth -auth /var/lib/gdm/:0.Xauth
kdm: -auth /var/lib/kdm/A:0-crWk72
     -auth /var/run/xauth/A:0-crWk72
xdm: -auth /var/lib/xdm/authdir/authfiles/A:0-XQvaJk
dtlogin: -auth /var/dt/A:0-UgaaXa

That is what we need to do, find and use the raw display manager MIT-MAGIC-COOKIE file.

Along the output of

$ systemctl status sddm

we will find something like

CGroup: /system.slice/sddm.service
        |-650 /usr/bin/sddm
        `-660 /usr/lib/Xorg -nolisten tcp -auth /var/run/sddm/{$somelongstring} -background none -noreset -displayfd 17 -seat seat0 vt1

Simply fetch x11vnc the aforementioned cookie file,

# x11vnc --display $DISPLAY -auth /var/run/sddm/{$somelongstring}

Note that such operation needs to be executed as root.

Now you will have an X11 VNC server running on your machine, and will be able to unlock the greeter screen from a VNC connection through any device, which may be your smartphone as well.

Perhaps someone can come up with a simpler and/or easier solution, where SSH and VNC connections are not needed, and a line of command would suffice. This approach, however, is rather fast and should solve your problem.

For different service managers, desktop managers, and VNC servers, the commands here have to be adapted accordingly.