Help locally displaying KDE desktop via x11vnc piped through ssh from Tumbleweed headless remote PC?

English Applications
1

I am getting an “Authorization required, but no authorization protocol specified” when unsuccessfully trying to connect to a Tumbleweed headless workstation via x11vnc piped through ssh (to locally display the remote Tumbleweed’s KDE display).

I’ve successfully been doing the same identical access method (with commands below) for over a decade with various versions of openSUSE.

Most recent success, using this method, on this identical headless PC, was less than 2 days ago, accessing this same headless PC from a different PC (which is running openSUSE-LEAP-15.2), successfully accessing the x11vnc server running on LEAP-15.3 on this headless PC. Now instead it fails with Tumbleweed installed on the headless PC.

I note the previous success (with LEAP-15.3) displayed locally the KDE desktop from the remote headless PC.

Background: I ‘updated’ the headless PC’s LEAP-15.3 to Tumbleweed yesterday. I can no longer pipe x11vnc via ssh, as I constantly get the noted error (after sending the lengthy ‘ssh’ command which I note below). As best I can determine, XWindow is running on this headless Tumbleweed display (despite it being headless). The “only” thing changed was the update from LEAP-15.3 to Tumbleweed. Here is what I believe to be the salient part in the bash shell after sending the ‘ssh/x11vnc command’:


12/01/2022 13:27:42 XOpenDisplay(":0") failed.
12/01/2022 13:27:42 Trying again with XAUTHLOCALHOSTNAME=localhost ...
Authorization required, but no authorization protocol specified

To confirm LEAP-15.2 not the issue, on my LEAP-15.3 laptop, I also tried/failed to display the remote headless Tumblweed PC’s KDE display, obtaining identical errors.

When the remote PC had LEAP-15.3 (instead of Tumbleweed), this is the command that I used previous to successfully obtain a remote KDE display:


ssh -t -L 5900:localhost:5900 oldcpu@xxx.xxx.x.xxx 'x11vnc -localhost -nolookup -nopw -ncache 10 -noxdamage -display :0'

where xxx.xxx.x.xxx has an IP address that I am not showing here.

and on the same PC to view the KDE display sent via ssh from the headless workstation:


vncviewer encodings "tight copyrect hextile" localhost:0

as noted that worked yesterday, locally showing the remote’s KDE display, when this “Tumbleweed” remote headless PC instead had LEAP-15.3 on it.

My guess is something has changed wrt xauthority between LEAP-15.3 and Tumbleweed, resulting in this techinque that I have been using for more than a decade to no longer function. I suspect this PC being ‘headless’ is not the issue, but rather it is something new in Tumbleweed?

I would like to fix this without switching to a different vnc method, if possible (as my review of openSUSE forum vnc help threads suggests that trying a different vnc app (which I prefer not do do) is the most common suggestion).

I don’t know if I know the correct question to ask … but the one question that comes to my mind is how do I specifify the correct authorisation protocol?

I don’t know if relevant, but as near as I can determine, the KDE Tumbleweed on a headless PC uses ssdm display manager. I note that access to this remote Tumbleweed PC via “ssh -X” works ok and I can run apps on the headless Tumbleweed PC (and display the apps locally).

But I would like to be able to remotely display the full KDE desktop, just like I did a couple of days ago (when it was LEAP-15.3) using x11vnc piped via ssh.

I have surfed a bit on this … and I wonder if this is a Tumbleweed bug that maybe has not been reported ( https://unix.stackexchange.com/questions/641241/every-x11-working-app-run-from-shell-shows-no-protocol-specified ) … or is this just me screwing up ?
.

2

I took a look at the “x11vnc” man page – <https://linux.die.net/man/1/x11vnc&gt; –

  • It ain’t short but, it’s fairly concise …

Are you absolutely certain that, a new (Tumbleweed) configuration parameter at the (headless) x11vnc server end of the connection isn’t needed?
[HR][/HR]

Unlikely … >:)

3

Hi
Just to be sure, the headless system is starting X11 rather than Wayland?

4

Many thanks for that suggestion. I did spend 30 minutes trawling through that, and a few hours surfing many sites - to no avail.

Purportedly, if one ssh’s in, then that ssh tunneling is supposed to provide the needed authentication. And that has been the case for every openSUSE up to and including LEAP-15.3. … but it fails on Tumbleweed.

In short, ‘NO’ … I am not sure. If there is, approximately 4 hours of surfing yielded nothing to provide evidence that is the case - of course thou I could have missed such. Rarely do I spend that much time on an issue.

But if there is, then Tumbleweed is different than every other openSUSE version prior.

5

I looked at the Xorg.log.0 file and spotted nothing to say it was Wayland. Is there anything obvious I should see if it is Wayland? I could have missed such I guess.

6

Hi
There has been a lot of service hardening going on with Tumbleweed, especially with services, you have copied over your ssh key over to the remote system etc?

7

I did not copy anything over. I believe the old key still present. Note I can ssh in without any problem. ssh -X runs fine to open applications on the headless Tumbleweed, and display locally (on different LEAP-15.2 and 15.3 PCs). But trying to get the KDE desktop to display via x11vnc (tunneled via ssh) fails.

8

Hi
So can you confirm if Plasma is running wayland or X11? Can you try iceWM instead, just to see if it’s a system issue or a desktop issue.

9

SDDM is using file with random name to store magic cookie ($XAUTHORITY) instead of default file location and you need to use x11vnc parameter -auth with correct filename. To get it you could use something like this hack:

systemctl --user show-environment  | grep XAUTHORITY= | cut -d'=' -f2

And x11vnc even displays the whole page of hints why connection may have failed after those lines you have shown and that you gratuitously removed. The first thing those hints mention is correct -auth parameter.

10

I had to surf to figure out how to do that … rotfl! … and when I ssh’d into the PC :


oldcpu@oldcorei7:~> echo $XDG_SESSION_TYPE
tty
oldcpu@oldcorei7:~> 
oldcpu@oldcorei7:~> loginctl show-session $(loginctl show-user $(whoami) -p Display --value) -p Type --value
x11
oldcpu@oldcorei7:~>

… I call this PC “oldcorei7” (as it has a core-i7-920 CPU) . … So it reads to be X11 running.

Thanks for suggestion. I’ll give that I try after I try a few other ideas first.

11

Thanks. That partly worked. See below … (where I changed the authentication file name to xauth_XXXXX for the purpose of this post):


oldcpu@oldcorei7:~> systemctl --user show-environment  | grep XAUTHORITY= | cut -d'=' -f2
/run/user/1000/xauth_XXXXX
oldcpu@oldcorei7:~> exit
logout
Connection to 192.168.2.102 closed.
oldcpu@X1-Carbon-G9:~> ssh -t -L 5900:localhost:5900 oldcpu@192.168.2.102 'x11vnc -localhost -nolookup -nopw -ncache 10 -noxdamage -auth /run/user/1000/xauth_XXXXX -display :0'
Password: 
13/01/2022 11:22:25 x11vnc version: 0.9.16 lastmod: 2019-01-05  pid: 5886
13/01/2022 11:22:25 Using X display :0
13/01/2022 11:22:25 rootwin: 0x50e reswin: 0x800001 dpy: 0x66ecc220
13/01/2022 11:22:25 
13/01/2022 11:22:25 ------------------ USEFUL INFORMATION ------------------
13/01/2022 11:22:25 
13/01/2022 11:22:25 Wireframing: -wireframe mode is in effect for window moves.
13/01/2022 11:22:25   If this yields undesired behavior (poor response, painting
13/01/2022 11:22:25   errors, etc) it may be disabled:
13/01/2022 11:22:25    - use '-nowf' to disable wireframing completely.
13/01/2022 11:22:25    - use '-nowcr' to disable the Copy Rectangle after the
13/01/2022 11:22:25      moved window is released in the new position.
13/01/2022 11:22:25   Also see the -help entry for tuning parameters.
13/01/2022 11:22:25   You can press 3 Alt_L's (Left "Alt" key) in a row to 
13/01/2022 11:22:25   repaint the screen, also see the -fixscreen option for
13/01/2022 11:22:25   periodic repaints.
13/01/2022 11:22:25 
13/01/2022 11:22:25 XFIXES available on display, resetting cursor mode
13/01/2022 11:22:25   to: '-cursor most'.
13/01/2022 11:22:25   to disable this behavior use: '-cursor arrow'
13/01/2022 11:22:25   or '-noxfixes'.
13/01/2022 11:22:25 using XFIXES for cursor drawing.
13/01/2022 11:22:25 GrabServer control via XTEST.
13/01/2022 11:22:25 
13/01/2022 11:22:25 Scroll Detection: -scrollcopyrect mode is in effect to
13/01/2022 11:22:25   use RECORD extension to try to detect scrolling windows
13/01/2022 11:22:25   (induced by either user keystroke or mouse input).
13/01/2022 11:22:25   If this yields undesired behavior (poor response, painting
13/01/2022 11:22:25   errors, etc) it may be disabled via: '-noscr'
13/01/2022 11:22:25   Also see the -help entry for tuning parameters.
13/01/2022 11:22:25   You can press 3 Alt_L's (Left "Alt" key) in a row to 
13/01/2022 11:22:25   repaint the screen, also see the -fixscreen option for
13/01/2022 11:22:25   periodic repaints.
13/01/2022 11:22:25 
13/01/2022 11:22:25 Client Side Caching: -ncache mode is in effect to provide
13/01/2022 11:22:25   client-side pixel data caching.  This speeds up
13/01/2022 11:22:25   iconifying/deiconifying windows, moving and raising
13/01/2022 11:22:25   windows, and reposting menus.  In the simple CopyRect
13/01/2022 11:22:25   encoding scheme used (no compression) a huge amount
13/01/2022 11:22:25   of extra memory (20-100MB) is used on both the server and
13/01/2022 11:22:25   client sides.  This mode works with any VNC viewer.
13/01/2022 11:22:25   However, in most you can actually see the cached pixel
13/01/2022 11:22:25   data by scrolling down, so you need to re-adjust its size.
13/01/2022 11:22:25   See http://www.karlrunge.com/x11vnc/faq.html#faq-client-caching.
13/01/2022 11:22:25   If this mode yields undesired behavior (poor response,
13/01/2022 11:22:25   painting errors, etc) it may be disabled via: '-ncache 0'
13/01/2022 11:22:25   You can press 3 Alt_L's (Left "Alt" key) in a row to 
13/01/2022 11:22:25   repaint the screen, also see the -fixscreen option for
13/01/2022 11:22:25   periodic repaints.
13/01/2022 11:22:25 
13/01/2022 11:22:25 XKEYBOARD: number of keysyms per keycode 7 is greater
13/01/2022 11:22:25   than 4 and 52 keysyms are mapped above 4.
13/01/2022 11:22:25   Automatically switching to -xkb mode.
13/01/2022 11:22:25   If this makes the key mapping worse you can
13/01/2022 11:22:25   disable it with the "-noxkb" option.
13/01/2022 11:22:25   Also, remember "-remap DEAD" for accenting characters.
13/01/2022 11:22:25 
13/01/2022 11:22:25 X FBPM extension not supported.
Xlib:  extension "DPMS" missing on display ":0".
13/01/2022 11:22:25 X display is not capable of DPMS.
13/01/2022 11:22:25 --------------------------------------------------------
13/01/2022 11:22:25 
13/01/2022 11:22:25 Default visual ID: 0x21
13/01/2022 11:22:25 Read initial data from X display into framebuffer.
13/01/2022 11:22:25 initialize_screen: fb_depth/fb_bpp/fb_Bpl 24/32/5120
13/01/2022 11:22:25 
13/01/2022 11:22:25 X display :0 is 32bpp depth=24 true color
13/01/2022 11:22:25 
13/01/2022 11:22:25 Autoprobing TCP port 
13/01/2022 11:22:25 Autoprobing selected TCP port 5900
13/01/2022 11:22:25 Autoprobing TCP6 port 
13/01/2022 11:22:25 rfbListenOnTCP6Port: error in bind IPv6 socket: Cannot assign requested address
... deleted MANY duplicates of above line
13/01/2022 11:22:25 rfbListenOnTCP6Port: error in bind IPv6 socket: Cannot assign requested address
13/01/2022 11:22:25 Failure autoprobing: Cannot assign requested address
13/01/2022 11:22:25 listen6: bind: Cannot assign requested address
13/01/2022 11:22:25 Not listening on IPv6 interface.
13/01/2022 11:22:25 
13/01/2022 11:22:25 Xinerama is present and active (e.g. multi-head).
13/01/2022 11:22:25 Xinerama: number of sub-screens: 1
13/01/2022 11:22:25 Xinerama: no blackouts needed (only one sub-screen)
13/01/2022 11:22:25 
13/01/2022 11:22:25 fb read rate: 1403 MB/sec
13/01/2022 11:22:25 fast read: reset -wait  ms to: 10
13/01/2022 11:22:25 fast read: reset -defer ms to: 10
13/01/2022 11:22:25 The X server says there are 10 mouse buttons.
13/01/2022 11:22:25 screen setup finished.
13/01/2022 11:22:25 

The VNC desktop is:      localhost:0
PORT=5900
13/01/2022 11:22:38 Got connection from client 127.0.0.1
13/01/2022 11:22:38   0 other clients
13/01/2022 11:22:38 Normal socket connection
13/01/2022 11:22:38 check_access: client 127.0.0.1 matches host 127.0.0.1
13/01/2022 11:22:38 Disabled X server key autorepeat.
13/01/2022 11:22:38   to force back on run: 'xset r on' (3 times)
13/01/2022 11:22:38 incr accepted_client=1 for 127.0.0.1:34656  sock=9
13/01/2022 11:22:38 Client Protocol Version 3.8
13/01/2022 11:22:38 Protocol version sent 3.8, using 3.8
13/01/2022 11:22:38 Send channel security type 'none'
13/01/2022 11:22:38 rfbProcessClientSecurityType: executing handler for type 1
13/01/2022 11:22:38 rfbProcessClientSecurityType: returning securityResult for client rfb version >= 3.8
13/01/2022 11:22:38 rfbProcessClientNormalMessage: ignoring unsupported encoding type Enc(0xFFFFFEC6)
13/01/2022 11:22:38 rfbProcessClientNormalMessage: ignoring unsupported encoding type Enc(0x574D5664)
13/01/2022 11:22:38 Enabling full-color cursor updates for client 127.0.0.1
13/01/2022 11:22:38 Enabling X-style cursor updates for client 127.0.0.1
13/01/2022 11:22:38 Enabling NewFBSize protocol extension for client 127.0.0.1
13/01/2022 11:22:38 Enabling ExtDesktopSize protocol extension for client 127.0.0.1
13/01/2022 11:22:38 rfbProcessClientNormalMessage: ignoring unsupported encoding type Enc(0xFFFFFEFB)
13/01/2022 11:22:38 rfbProcessClientNormalMessage: ignoring unsupported encoding type Enc(0x574D5668)
13/01/2022 11:22:38 rfbProcessClientNormalMessage: ignoring unsupported encoding type Enc(0xFFFFFECD)
13/01/2022 11:22:38 Enabling LastRect protocol extension for client 127.0.0.1
13/01/2022 11:22:38 rfbProcessClientNormalMessage: ignoring unsupported encoding type Enc(0xC0A1E5CE)
13/01/2022 11:22:38 rfbProcessClientNormalMessage: ignoring unsupported encoding type Enc(0xFFFFFEC7)
13/01/2022 11:22:38 rfbProcessClientNormalMessage: ignoring unsupported encoding type Enc(0xFFFFFEC8)
13/01/2022 11:22:38 rfbProcessClientNormalMessage: ignoring unsupported encoding type Enc(0xFFFFFEFE)
13/01/2022 11:22:38 Using compression level 2 for client 127.0.0.1
13/01/2022 11:22:38 Using image quality level 8 for client 127.0.0.1
13/01/2022 11:22:38 Using JPEG subsampling 0, Q92 for client 127.0.0.1
13/01/2022 11:22:38 Using tight encoding for client 127.0.0.1
13/01/2022 11:22:38 Sending rfbEncodingExtDesktopSize for size (1280x12288) 
13/01/2022 11:22:38 Client requested resolution change to (1280x1081)
13/01/2022 11:22:38 Sending rfbEncodingExtDesktopSize for size (1280x12288) resize prohibited
13/01/2022 11:22:38 client 1 network rate 5188.4 KB/sec (661403.4 eff KB/sec)
13/01/2022 11:22:38 client 1 latency:  2.2 ms
13/01/2022 11:22:38 dt1: 0.0608, dt2: 0.0354 dt3: 0.0022 bytes: 493554
13/01/2022 11:22:38 link_rate: LR_LAN - 2 ms, 5188 KB/s
13/01/2022 11:22:38 copy_tiles: allocating first_line at size 41
13/01/2022 11:22:38 client_set_net: 127.0.0.1  0.0000
13/01/2022 11:22:42 set_ncache_xrootpmap: trying root background
13/01/2022 11:22:42 snapshotting background...
13/01/2022 11:22:42 done.
13/01/2022 11:22:47 created selwin: 0x80002e
13/01/2022 11:22:47 called initialize_xfixes()

I then ran in a different bash shell on my local PC :


oldcpu@X1-Carbon-G9:~> vncviewer encodings "tight copyrect hextile" localhost:0

TigerVNC Viewer 64-bit v1.10.1
Copyright (C) 1999-2019 TigerVNC Team and many others (see README.rst)
See https://www.tigervnc.org for information on TigerVNC.

Thu Jan 13 11:22:37 2022
 DecodeManager: Detected 8 CPU core(s)
 DecodeManager: Creating 4 decoder thread(s)
 CConn:       Connected to host localhost port 5900

Thu Jan 13 11:22:38 2022
 CConnection: Server supports RFB protocol version 3.8
 CConnection: Using RFB protocol version 3.8
 CConnection: Choosing security type None(1)
 CConn:       Using pixel format depth 24 (32bpp) little-endian rgb888
 CConn:       SetDesktopSize failed: 1

So I have the KDE desktop showing remotely … However the remote session does not recognize my keyboard - only mouse moves.

Maybe I need to use “-noxkb” option. …

I’m going to check the Xorg.0.log file and then possibly reboot that PC and try again.

I am getting close.

Thanks for the help.

[Edit : re: the ipv6 errors - I have that deliberately disabled]

12

My mistake.

The keyboard does ‘partly’ work … but the session comes up with KDE running with root permissions.

Opening a konsole and it asks for a password. Entering the root password and it works, but CAPS do not yet work. …

I am still scoping the quirks here … obviously I have something wrong, albeit its interesting to be able to remotely display the KDE desktop … I just need to revert it back to a regular user. … Given I ssh and login as a regular user I don’t understand why the desktop comes up as root (albeit it does ask for a password). … Puzzling.

13

I noted further, that I need to obtain the authentication for each reboot of this Tumbleweed system (as it changes)


systemctl --user show-environment  | grep XAUTHORITY= | cut -d'=' -f2

… and then use that in the ssh command that runs x11vnc. If this is an ssdm display manager characteristic, I prefer not to do such.

so I guess next will be to check a different display manager: https://en.opensuse.org/SDB:Change_Display_Manager

I feel like I am 6 decades younger, learning all these new things. rotfl!

14

A refinement to this. “shift” “key” does not bring caps (still lower case), but if I press “CapsLock” then all subsequent letters will be capitals until I press “CapsLock” again. … Interesting.

I guess the keyboard mapping is not so good (this is using my Lenovo X1 Carbon Generation-9 laptop (running openSUSE LEAP-15.3) to access this remote Tumbleweed PC.

I still have yet to switch to a different display manager and test that.
.

15

I note on this tumbleweed PC:


oldcorei7:~ # update-alternatives --list default-displaymanager
/usr/lib/X11/displaymanagers/console
/usr/lib/X11/displaymanagers/lightdm
/usr/lib/X11/displaymanagers/sddm
/usr/lib/X11/displaymanagers/xdm

I will check YaST for iceWM, as its not nominally on the list.

16

iceWM is installed. I now note:


oldcorei7:~ # /usr/sbin/update-alternatives --list default-xsession.desktop
/usr/share/xsessions/icewm-session.desktop
/usr/share/xsessions/plasma5.desktop

Now to figure out how to switch to it … ??

… although I wonder if it makes more sense to try a different display manager prior to trying a different window manager. … Which is least intrusive?

17

I am taking a bit of a step back here … and pondering the way forward.

I recall now the main reason that I have been using x11vnc all these years, is that it connects to the existing graphical session. This was incredibly useful for a decade, when I lived in Europe, and my mother lived in North America, and I would ssh/x11vnc into her PC in North America, and I would remotely help her and remotely maintain her PC, and she could see what I was doing, and I could see what she was doing.

Of course, that is no longer the case, and I am now simply trying to connect to a PC in the next room which has no monitor attached … ie no existing graphical session to connect to. I have read that most other vnc servers will spawn an entirely new graphical session. Maybe that is what I should be doing. … or maybe I should use x2go.

Am I making this unnecessarily complex for myself with x11vnc? Maybe now is the time to switch to a different vnc server, or to x2go ? ( all of which I would need to learn from scratch)

Maybe x11vnc is not the correct way to go about this …

Sometimes I am a little slow.

18

While pondering what to do next … I did a quick switch to lightdm from ssdm.


oldcpu@oldcorei7:~> sudo update-alternatives --set default-displaymanager /usr/lib/X11/displaymanagers/lightdm
[sudo] password for root: 
update-alternatives: using /usr/lib/X11/displaymanagers/lightdm to provide /usr/lib/X11/displaymanagers/default-displaymanager (default-displaymanager) in manual mode
oldcpu@oldcorei7:~>

I then rebooted the Tumbleweed PC (via ‘shutdown -r now’ ) and this time I did not need the authentication to loggin … ie this works :

In one bash shell on the PC (LEAP-15.3) that I am sitting at:


ssh -t -L 5900:localhost:5900 oldcpu@ip-addess-of-tumbleweed-pc 'x11vnc -localhost -nolookup -nopw -ncache 10 -noxdamage -display :0'

and then in a second bash shell on this same PC:


vncviewer encodings "tight copyrect hextile" localhost:0

and it brings up the Tumbleweed KDE on the LEAP-15.3 PC where I am sitting. This time the keyboard ‘shift’ key works properly.

However, again the bash shell (and not the desktop) comes up as user root !! in every bash shell on that PC I open. …Checking the settings I see that in this Tumbleweed update the konsole always comes up as root (as it has “su -” as a default command setting). I changed the profile to be a regular user and now that does not happen.

I don’t know if that (konsole always coming up as user root, asking for a password) was a design decision, but I don’t like that approach if it is indeed the intended way forward for Tumbleweed.

19

I guess I should summarize to note everything now appears to be working as before. … I am still testing out various aspects of this headless Tumbleweed setup, but at present it appears to be functioning similar to how I remember LEAP-15.2 was working (I did not test its LEAP-15.3 setup very much).

My thanks to all on this thread who participated and helped me. … Once again (for me) its been a learning experience.

20

I used x2go. And this is work fine on leap 15.2 and old tumbleweed, But on Leap 15.3 and fresh tumbleweed it did not connect to remote session, or another session. X2go only work in terminal mode. I don’t know why this is happen.