adds remote desktop
This commit is contained in:
parent
96a4458eef
commit
bddbcd78b2
Binary file not shown.
|
After Width: | Height: | Size: 30 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 37 KiB |
|
|
@ -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.
|
||||
|
||||
|
||||
|
||||
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.
|
||||
|
||||
|
||||
|
||||
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!
|
||||
Loading…
Reference in New Issue