waldek
/
linux_course_doc
1
0
Fork 0
Code Issues 2 Pull Requests Projects Releases Wiki Activity

Compare commits

base: waldek:93270e3901e6fc3b699a95101ea7b70cfb707ffd
Branches Tags
waldek:master
..
compare: waldek:548ed18791b21dd6bc670e3de97e25b60ccb78b8
Branches Tags
waldek:master

2 Commits
93270e3901 ... 548ed18791

Author SHA1 Message Date
waldek 548ed18791 Merge branch 'master' of ssh://86thumbs.net:3022/waldek/linux_course_doc 2021-09-13 22:20:50 +02:00
waldek bddbcd78b2 adds remote desktop 2021-09-13 22:20:45 +02:00
3 changed files with 544 additions and 0 deletions
Show Stats Expand all files Collapse all files

BIN
modules/qualifying/assets/gnome_error.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 30 KiB

BIN
modules/qualifying/assets/rdp_windows.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 37 KiB

544
modules/qualifying/learning_remote_graphical_interaction.md Normal file
View File

@ -0,0 +1,544 @@
# Remote control on Linux
## Console
For console control of a Linux machine `ssh` is **the** way to go.
This is what we've been using up until now and should be self evident to you.
To be able to multi task and have long running processes on a remote server you can use `tmux` or `screen`.
Again, nothing new here but let's try the following.
I installed a Debian 11 machine with graphical environment and I can log in over `ssh` as follows.
It shows a running `X11` session which is the desktop environment I'm using on the virtual machine.
```bash
➜ ~ git:(master) ✗ ssh waldek@192.168.0.195
waldek@192.168.0.195's password:
Linux debian 5.10.0-8-amd64 #1 SMP Debian 5.10.46-4 (2021-08-03) x86_64
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Mon Sep 13 15:11:41 2021 from 192.168.0.16
waldek@debian:~$ ps a
PID TTY STAT TIME COMMAND
611 tty1 Ss+ 0:00 /sbin/agetty -o -p -- \u --noclear tty1 linux
1142 tty7 Ssl+ 0:07 /usr/lib/xorg/Xorg :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitc
1459 pts/1 Ss+ 0:00 bash
2259 pts/0 Ss 0:00 -bash
2262 pts/0 R+ 0:00 ps a
waldek@debian:~$
```
We can use all console applications we know, such as `htop` and `vim` but what about the *graphical* ones?
Let's try and see what we can do.
`firefox` is installed on the remote machine so I *should* be able to launch it.
```bash
waldek@debian:~$ firefox
(firefox-esr:2275): Gtk-WARNING **: 15:14:42.460: Locale not supported by C library.
Using the fallback 'C' locale.
Error: no DISPLAY environment variable specified
waldek@debian:~$
```
What is this `DISPLAY` variable?
On the ssh connection we can have a look at how it's set with the following command.
It seems to be *empty*
```bash
waldek@debian:~$ echo $DISPLAY
waldek@debian:~$
```
On the graphical session we do the same and get the following.
```bash
waldek@debian:~$ echo $DISPLAY
:0
waldek@debian:~$
```
OK, there seems to a difference between both terminals here.
What would happen if we manually set the `DISPLAY` in the `ssh` connection?
Let's try this out.
```bash
waldek@debian:~$ export DISPLAY=:0
waldek@debian:~$ firefox
(firefox-esr:2298): Gtk-WARNING **: 15:19:37.681: Locale not supported by C library.
Using the fallback 'C' locale.
(/usr/lib/firefox-esr/firefox-esr:2348): Gtk-WARNING **: 15:19:38.329: Locale not supported by C library.
Using the fallback 'C' locale.
(/usr/lib/firefox-esr/firefox-esr:2391): Gtk-WARNING **: 15:19:38.818: Locale not supported by C library.
Using the fallback 'C' locale.
(/usr/lib/firefox-esr/firefox-esr:2414): Gtk-WARNING **: 15:19:39.103: Locale not supported by C library.
Using the fallback 'C' locale.
```
You should see `firefox` open up on the graphical desktop!
The `man X` pages explain this variable as follows:
```bash
DISPLAY NAMES
From the user's perspective, every X server has a display name of the form:
hostname:displaynumber.screennumber
This information is used by the application to determine how it should connect to the server and which screen
it should use by default (on displays with multiple monitors):
hostname
The hostname specifies the name of the machine to which the display is physically connected. If the
hostname is not given, the most efficient way of communicating to a server on the same machine will be
used.
displaynumber
The phrase "display" is usually used to refer to a collection of monitors that share a common set of
input devices (keyboard, mouse, tablet, etc.). Most workstations tend to only have one display.
Larger, multi-user systems, however, frequently have several displays so that more than one person can
be doing graphics work at once. To avoid confusion, each display on a machine is assigned a display
number (beginning at 0) when the X server for that display is started. The display number must always be given in a display name.
screennumber
Some displays share their input devices among two or more monitors. These may be configured as a sin-
gle logical screen, which allows windows to move across screens, or as individual screens, each with
their own set of windows. If configured such that each monitor has its own set of windows, each screen
is assigned a screen number (beginning at 0) when the X server for that display is started. If the
screen number is not given, screen 0 will be used.
```
## X11 over SSH
While opening up a graphical program onto the remote screen can be handy, most often you'll want to actually interact with the program on your local screen.
This can be achieved via *Xforwarding* over `ssh`.
Let's dive into the trusty `man sshd_config` pages and look for all stuff related to `X11`.
```bash
X11DisplayOffset
Specifies the first display number available for sshd(8)'s X11 forwarding. This prevents sshd from in-
terfering with real X11 servers. The default is 10.
X11Forwarding
Specifies whether X11 forwarding is permitted. The argument must be yes or no. The default is no.
When X11 forwarding is enabled, there may be additional exposure to the server and to client displays if
the sshd(8) proxy display is configured to listen on the wildcard address (see X11UseLocalhost), though
this is not the default. Additionally, the authentication spoofing and authentication data verification
and substitution occur on the client side. The security risk of using X11 forwarding is that the
client's X11 display server may be exposed to attack when the SSH client requests forwarding (see the
warnings for ForwardX11 in ssh_config(5)). A system administrator may have a stance in which they want
to protect clients that may expose themselves to attack by unwittingly requesting X11 forwarding, which
can warrant a no setting.
Note that disabling X11 forwarding does not prevent users from forwarding X11 traffic, as users can al-
ways install their own forwarders.
X11UseLocalhost
Specifies whether sshd(8) should bind the X11 forwarding server to the loopback address or to the wild-
card address. By default, sshd binds the forwarding server to the loopback address and sets the hostname
part of the DISPLAY environment variable to localhost. This prevents remote hosts from connecting to the
proxy display. However, some older X11 clients may not function with this configuration.
X11UseLocalhost may be set to no to specify that the forwarding server should be bound to the wildcard
address. The argument must be yes or no. The default is yes.
XAuthLocation
Specifies the full pathname of the xauth(1) program, or none to not use one. The default is
/usr/bin/xauth.
```
We'll need to make sure a few setting are set in remote servers sshd configuration file, restart the server and try to launch a graphical application.
```bash
waldek@debian:~$ grep "X11" /etc/ssh/sshd_config
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
# X11Forwarding no
waldek@debian:~$
```
By default the forwarding seems to be on so why can't we see the firefox locally?
Turn out that the ssh *client* needs to ask for a fowarded connection to have it work out of the box.
A quick read of the `man ssh` pages gives us this explication.
```bash
-X Enables X11 forwarding. This can also be specified on a per-host basis in a configuration file.
X11 forwarding should be enabled with caution. Users with the ability to bypass file permissions on the
remote host (for the user's X authorization database) can access the local X11 display through the for-
warded connection. An attacker may then be able to perform activities such as keystroke monitoring.
For this reason, X11 forwarding is subjected to X11 SECURITY extension restrictions by default. Please
refer to the ssh -Y option and the ForwardX11Trusted directive in ssh_config(5) for more information.
(Debian-specific: X11 forwarding is not subjected to X11 SECURITY extension restrictions by default, be-
cause too many programs currently crash in this mode. Set the ForwardX11Trusted option to "no" to re-
store the upstream behaviour. This may change in future depending on client-side improvements.)
-x Disables X11 forwarding.
-Y Enables trusted X11 forwarding. Trusted X11 forwardings are not subjected to the X11 SECURITY extension
controls.
(Debian-specific: In the default configuration, this option is equivalent to -X, since ForwardX11Trusted
defaults to "yes" as described above. Set the ForwardX11Trusted option to "no" to restore the upstream
behaviour. This may change in future depending on client-side improvements.)
```
Let's add the `-X` flag and see how it behaves now.
A firefox window should open up on your local screen!
```bash
➜ ~ git:(master) ✗ ssh -X waldek@192.168.0.195
waldek@192.168.0.195's password:
Linux debian 5.10.0-8-amd64 #1 SMP Debian 5.10.46-4 (2021-08-03) x86_64
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Mon Sep 13 15:29:56 2021 from 192.168.0.16
waldek@debian:~$ echo $DISPLAY
localhost:10.0
waldek@debian:~$ firefox
(firefox-esr:3415): Gtk-WARNING **: 15:48:38.880: Locale not supported by C library.
Using the fallback 'C' locale.
(/usr/lib/firefox-esr/firefox-esr:3461): Gtk-WARNING **: 15:48:39.464: Locale not supported by C library.
Using the fallback 'C' locale.
(/usr/lib/firefox-esr/firefox-esr:3508): Gtk-WARNING **: 15:48:40.522: Locale not supported by C library.
Using the fallback 'C' locale.
(/usr/lib/firefox-esr/firefox-esr:3540): Gtk-WARNING **: 15:48:41.772: Locale not supported by C library.
Using the fallback 'C' locale.
```
## RDP
While Xforwarding over `ssh` is super handy for single applications, it becomes tricky to expose a full desktop environment over it.
A great alternative is the [Remote Desktop Protocol](https://en.wikipedia.org/wiki/Remote_Desktop_Protocol) which is a proprietary protocol by Microsoft.
There are open source alternatives but RDP works pretty well out of the box on Linux and Windows 10 comes with a client installed by default.
This makes it a good go to candidate for quick connections.
On a clean Debian you install the `xrdp` package.
```
waldek@debian:~$ sudo apt install xrdp
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
xrdp is already the newest version (0.9.12-1.1).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
waldek@debian:~$ sudo systemctl status xrdp --no-pager
● xrdp.service - xrdp daemon
Loaded: loaded (/lib/systemd/system/xrdp.service; enabled; vendor preset: enabled)
Active: active (running) since Mon 2021-09-13 15:34:13 CEST; 37min ago
Docs: man:xrdp(8)
man:xrdp.ini(5)
Main PID: 7020 (xrdp)
Tasks: 1 (limit: 4577)
Memory: 816.0K
CPU: 3.542s
CGroup: /system.slice/xrdp.service
└─7020 /usr/sbin/xrdp
Sep 13 16:03:52 debian xrdp[20045]: (20045)(140028929824576)[INFO ] xrdp_wm_log_msg: login successful for display 11
Sep 13 16:03:52 debian xrdp[20045]: (20045)(140028929824576)[DEBUG] xrdp_wm_log_msg: started connecting
Sep 13 16:03:52 debian xrdp[20045]: (20045)(140028929824576)[INFO ] lib_mod_log_peer: xrdp_pid=20045 connected to…rt=52421
Sep 13 16:03:52 debian xrdp[20045]: (20045)(140028929824576)[DEBUG] xrdp_wm_log_msg: connected ok
Sep 13 16:03:52 debian xrdp[20045]: (20045)(140028929824576)[DEBUG] xrdp_mm_connect_chansrv: chansrv connect successful
Sep 13 16:03:52 debian xrdp[20045]: (20045)(140028929824576)[DEBUG] Closed socket 16 (AF_INET6 ::1 port 55722)
Sep 13 16:09:25 debian xrdp[20045]: (20045)(140028929824576)[DEBUG] Closed socket 12 (AF_INET6 ::ffff:192.168.0.2…rt 3389)
Sep 13 16:09:25 debian xrdp[20045]: (20045)(140028929824576)[DEBUG] xrdp_mm_module_cleanup
Sep 13 16:09:25 debian xrdp[20045]: (20045)(140028929824576)[DEBUG] Closed socket 17 (AF_UNIX)
Sep 13 16:09:25 debian xrdp[20045]: (20045)(140028929824576)[DEBUG] Closed socket 18 (AF_UNIX)
Hint: Some lines were ellipsized, use -l to show in full.
waldek@debian:~$
```
On your Windows client you can connect to machine and start a session.
![RDP client windows](./assets/rdp_windows.png)
On Linux `remmina` is a good all around client for `RDP`, `ssh` and `VNC` connections.
If you're running `GNOME` there is a high chance you'll get the following message.
![gnome error](./assets/gnome_error.png)
There is not much you can do about this and your best bet is to move to `xfce4` as desktop environment.
You can install both side by side and use gnome when sitting at the physical machine, and xfce4 over RDP.
The easiest way to *add* xfce4 to an existing installation is via `sudo tasksel`.
To set your default session you can do the following (tab complete works here!).
```bash
waldek@debianremote:~$ sudo update-alternatives --config x-session-manager
There are 3 choices for the alternative x-session-manager (providing /usr/bin/x-session-manager).
Selection Path Priority Status
------------------------------------------------------------
0 /usr/bin/gnome-session 50 auto mode
* 1 /usr/bin/gnome-session 50 manual mode
2 /usr/bin/startxfce4 50 manual mode
3 /usr/bin/xfce4-session 40 manual mode
Press <enter> to keep the current choice[*], or type selection number: 2
update-alternatives: using /usr/bin/startxfce4 to provide /usr/bin/x-session-manager (x-session-manager) in manual mode
waldek@debianremote:~$ sudo systemctl restart lightdm.service
waldek@debianremote:~$
```
Try to get an RDP session going and once you're logged in, try to run a parallel session via the lightdm display manager.
You'll log in but will get *kicked out* almost immediately.
This is because by default you can't have two sessions running at the same time on the same computer.
Try to connect from a different station to the same session again over RDP.
You'll get to log in, but the original one will be cut off.
This is the expected behavior, so not a bug, more of a feature!
Your session will stay running so you can disconnect and reconnect from a different location later.
## VNC
### Remote helping via x11vnc
If we need to connect to an running session to help out, or take over, the control of a Linux machine we can use `x11vnc` to do this.
This is a program that can expose *any* running screen over vnc, with or without a password!
In a terminal either via the virtual machine, or via ssh, you execute the following commands.
A vnc server is now running and you can connect to it with remmina or vncviewer.
As long as this x11vnc process is running we can connect to it.
```bash
waldek@debianremote:~$ sudo apt install x11vnc
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
x11vnc is already the newest version (0.9.16-7).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
waldek@debianremote:~$ x11vnc -display :0
###############################################################
#@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@#
#@ @#
#@ ** WARNING ** WARNING ** WARNING ** WARNING ** @#
#@ @#
#@ YOU ARE RUNNING X11VNC WITHOUT A PASSWORD!! @#
#@ @#
#@ This means anyone with network access to this computer @#
#@ may be able to view and control your desktop. @#
#@ @#
#@ >>> If you did not mean to do this Press CTRL-C now!! <<< @#
#@ @#
#@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@#
#@ @#
#@ You can create an x11vnc password file by running: @#
#@ @#
#@ x11vnc -storepasswd password /path/to/passfile @#
#@ or x11vnc -storepasswd /path/to/passfile @#
#@ or x11vnc -storepasswd @#
#@ @#
#@ (the last one will use ~/.vnc/passwd) @#
#@ @#
#@ and then starting x11vnc via: @#
#@ @#
#@ x11vnc -rfbauth /path/to/passfile @#
#@ @#
#@ an existing ~/.vnc/passwd file from another VNC @#
#@ application will work fine too. @#
#@ @#
#@ You can also use the -passwdfile or -passwd options. @#
#@ (note -passwd is unsafe if local users are not trusted) @#
#@ @#
#@ Make sure any -rfbauth and -passwdfile password files @#
#@ cannot be read by untrusted users. @#
#@ @#
#@ Use x11vnc -usepw to automatically use your @#
#@ ~/.vnc/passwd or ~/.vnc/passwdfile password files. @#
#@ (and prompt you to create ~/.vnc/passwd if neither @#
#@ file exists.) Under -usepw, x11vnc will exit if it @#
#@ cannot find a password to use. @#
#@ @#
#@ @#
#@ Even with a password, the subsequent VNC traffic is @#
#@ sent in the clear. Consider tunnelling via ssh(1): @#
#@ @#
#@ http://www.karlrunge.com/x11vnc/#tunnelling @#
#@ @#
#@ Or using the x11vnc SSL options: -ssl and -stunnel @#
#@ @#
#@ Please Read the documentation for more info about @#
#@ passwords, security, and encryption. @#
#@ @#
#@ http://www.karlrunge.com/x11vnc/faq.html#faq-passwd @#
#@ @#
#@ To disable this warning use the -nopw option, or put @#
#@ 'nopw' on a line in your ~/.x11vncrc file. @#
#@ @#
#@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@#
###############################################################
13/09/2021 20:47:13 x11vnc version: 0.9.16 lastmod: 2019-01-05 pid: 14610
13/09/2021 20:47:13 Using X display :0
13/09/2021 20:47:13 rootwin: 0x532 reswin: 0x2e00001 dpy: 0xbfe738d0
13/09/2021 20:47:13
13/09/2021 20:47:13 ------------------ USEFUL INFORMATION ------------------
13/09/2021 20:47:13 X DAMAGE available on display, using it for polling hints.
13/09/2021 20:47:13 To disable this behavior use: '-noxdamage'
13/09/2021 20:47:13
13/09/2021 20:47:13 Most compositing window managers like 'compiz' or 'beryl'
13/09/2021 20:47:13 cause X DAMAGE to fail, and so you may not see any screen
13/09/2021 20:47:13 updates via VNC. Either disable 'compiz' (recommended) or
13/09/2021 20:47:13 supply the x11vnc '-noxdamage' command line option.
13/09/2021 20:47:13
13/09/2021 20:47:13 Wireframing: -wireframe mode is in effect for window moves.
13/09/2021 20:47:13 If this yields undesired behavior (poor response, painting
13/09/2021 20:47:13 errors, etc) it may be disabled:
13/09/2021 20:47:13 - use '-nowf' to disable wireframing completely.
13/09/2021 20:47:13 - use '-nowcr' to disable the Copy Rectangle after the
13/09/2021 20:47:13 moved window is released in the new position.
13/09/2021 20:47:13 Also see the -help entry for tuning parameters.
13/09/2021 20:47:13 You can press 3 Alt_L's (Left "Alt" key) in a row to
13/09/2021 20:47:13 repaint the screen, also see the -fixscreen option for
13/09/2021 20:47:13 periodic repaints.
13/09/2021 20:47:13
13/09/2021 20:47:13 XFIXES available on display, resetting cursor mode
13/09/2021 20:47:13 to: '-cursor most'.
13/09/2021 20:47:13 to disable this behavior use: '-cursor arrow'
13/09/2021 20:47:13 or '-noxfixes'.
13/09/2021 20:47:13 using XFIXES for cursor drawing.
13/09/2021 20:47:13 GrabServer control via XTEST.
13/09/2021 20:47:13
13/09/2021 20:47:13 Scroll Detection: -scrollcopyrect mode is in effect to
13/09/2021 20:47:13 use RECORD extension to try to detect scrolling windows
13/09/2021 20:47:13 (induced by either user keystroke or mouse input).
13/09/2021 20:47:13 If this yields undesired behavior (poor response, painting
13/09/2021 20:47:13 errors, etc) it may be disabled via: '-noscr'
13/09/2021 20:47:13 Also see the -help entry for tuning parameters.
13/09/2021 20:47:13 You can press 3 Alt_L's (Left "Alt" key) in a row to
13/09/2021 20:47:13 repaint the screen, also see the -fixscreen option for
13/09/2021 20:47:13 periodic repaints.
13/09/2021 20:47:13
13/09/2021 20:47:13 XKEYBOARD:
13/09/2021 20:47:13 Switching to -xkb mode to recover these keysyms:
13/09/2021 20:47:13 xkb noxkb Keysym ("X" means present)
13/09/2021 20:47:13 --- ----- -----------------------------
13/09/2021 20:47:13 X 0x40 at
13/09/2021 20:47:13 X 0x23 numbersign
13/09/2021 20:47:13 X 0x5b bracketleft
13/09/2021 20:47:13 X 0x5d bracketright
13/09/2021 20:47:13 X 0x7b braceleft
13/09/2021 20:47:13 X 0x7d braceright
13/09/2021 20:47:13 X 0x7c bar
13/09/2021 20:47:13 X 0x5c backslash
13/09/2021 20:47:13
13/09/2021 20:47:13 If this makes the key mapping worse you can
13/09/2021 20:47:13 disable it with the "-noxkb" option.
13/09/2021 20:47:13
13/09/2021 20:47:13
13/09/2021 20:47:13 X FBPM extension not supported.
13/09/2021 20:47:13 X display is capable of DPMS.
13/09/2021 20:47:13 --------------------------------------------------------
13/09/2021 20:47:13
13/09/2021 20:47:13 Default visual ID: 0x21
13/09/2021 20:47:13 Read initial data from X display into framebuffer.
13/09/2021 20:47:13 initialize_screen: fb_depth/fb_bpp/fb_Bpl 24/32/3200
13/09/2021 20:47:13
13/09/2021 20:47:13 X display :0 is 32bpp depth=24 true color
13/09/2021 20:47:13
13/09/2021 20:47:13 Autoprobing TCP port
13/09/2021 20:47:13 Autoprobing selected TCP port 5901
13/09/2021 20:47:13 Autoprobing TCP6 port
13/09/2021 20:47:13 Autoprobing selected TCP6 port 5900
13/09/2021 20:47:13 Listening also on IPv6 port 5901 (socket 10)
13/09/2021 20:47:13
13/09/2021 20:47:13 Xinerama is present and active (e.g. multi-head).
13/09/2021 20:47:13 Xinerama: number of sub-screens: 1
13/09/2021 20:47:13 Xinerama: no blackouts needed (only one sub-screen)
13/09/2021 20:47:13
13/09/2021 20:47:13 fb read rate: 1355 MB/sec
13/09/2021 20:47:13 fast read: reset -wait ms to: 10
13/09/2021 20:47:13 fast read: reset -defer ms to: 10
13/09/2021 20:47:13 The X server says there are 10 mouse buttons.
13/09/2021 20:47:13 screen setup finished.
13/09/2021 20:47:13
13/09/2021 20:47:13 WARNING: You are running x11vnc WITHOUT a password. See
13/09/2021 20:47:13 WARNING: the warning message printed above for more info.
13/09/2021 20:47:13
The VNC desktop is: debianremote:1
PORT=5901
******************************************************************************
Have you tried the x11vnc '-ncache' VNC client-side pixel caching feature yet?
The scheme stores pixel data offscreen on the VNC viewer side for faster
retrieval. It should work with any VNC viewer. Try it by running:
x11vnc -ncache 10 ...
One can also add -ncache_cr for smooth 'copyrect' window motion.
More info: http://www.karlrunge.com/x11vnc/faq.html#faq-client-caching
```
You can combine both RDP and x11vnc as follows.
First you have to find out how the display of RDP is referenced.
The you create the x11vnc process and connect to it.
```bash
waldek@debianremote:~$ ps aux | grep xorgxrdp
waldek 3516 0.2 3.0 664264 118116 ? Sl 20:53 0:02 /usr/lib/xorg/Xorg :10 -auth .Xauthority -config xrdp/xorg.conf -noreset -nolisten tcp -logfile .xorgxrdp.%s.log
waldek 4333 0.0 0.0 6152 716 pts/0 S+ 21:11 0:00 grep xorgxrdp
waldek@debianremote:~$ x11vnc -display :10
```
On a different machine you run the following.
```bash
vncviewer 192.168.0.239:0
```
You probably realize this is super insecure so we should tunnel it over ssh!
Luckily this is quite easy to do.
We need to add `-allow localhost` to the `x11vnc` command, and then use the `-via` argument with `vncviewer`.
Both lines are noted below.
```bash
waldek@debianremote:~$ x11vnc -display :0 -allow localhost
```
```bash
vncviewer -via waldek@192.168.0.239 localhost:0
```
### Exposing the lightdm login screen
We can expose the actual login screen of lightdm over vnc to offer RDP like functionality but without the restrictions.
To do this we need to set the `-auth` flag of `x11vnc` to the `.Xauthority` file of `lightdm`.
On most disto's this can be found at `/var/lib/lightdm/.Xauthority`.
Because the login session runs as root we need to start the x11vnc as root as well.
You should limit to localhost for security reasons!
If you want the tunnel vnc process to keep running after you disconnect you should add the `-forever` argument together with the `-loop` one.
If you want more than one client to connect you can add the `-shared` argument.
Together with password for actual users and viewers the can become quite powerful!
```bash
x11vnc -rfbauth /etc/vncpasswd -auth /var/lib/lightdm/.Xauthority -display :0 -allow localhost -forever -loop -shared
```
Multiple users can now connect to the same session and to control the session they need a password.
This password can be set with the `vncpasswd` program.
You can make this into a systemd service to start at boot if you want!