Remote Administration

From Whonix
Jump to navigation Jump to search

Anonymous sysadmin of remote systems.

Introduction[edit]

Warning[edit]

Remote administration of any system should be considered a potential anonymity hazard, since it is not under the user's physical protection and could be compromised. All activities, all programs, everything should be assumed to be monitored by the host of the server (VPS, dedicated server, etc.).

Although counter-intuitive, it is necessary to follow all relevant recommendations in the Surfing Posting Blogging chapter to stay safe:

At a minimum, check the connection is encrypted / authenticated, because Virtual Network Computing (VNC)archive.org by default is unencrypted / unauthenticated. Possible methods:

  • Perhaps by tunneling VNC through SSH;
  • Running VNC through a Tor Onion Service;
  • Using both SSH and an Onion Service, for stronger encryption and authentication; or
  • Onion Services Authentication.

In case remote servers are exclusively available over .onion: Might get locked out due to Onion Services Reliability Issues.

SSH has a lower attack surface than VNC (for example Mouse Fingerprinting is not possible against simple SSH (terminal only, no X11 forwarding).

UDP[edit]

It is suggested to utilize software that does not require the User Datagram Protocol (UDP), for the following reason.

The Tor software does not support UDP. The feature request UDP over Torarchive.org was created in 2013 and closed as won't fixarchive.org by upstream, The Tor Project in 2018. It is therefore highly unlikely that the UDP over Tor feature will ever be implemented. This is unspecific to Whonix.

Tor provides a DnsPort but that is unrelated.

If UDP is urgently required in Whonix, a limited workaround is provided. For the most secure method, see Tunnel UDP over Tor.

Remmina[edit]

Remmina Logo

It is possible to remotely administer any operating system with GNU/Linux by using the Remminaarchive.org desktop client. Remmina supports multiple network protocols, including RDP, VNC, SPICE, NX, XDMCP, SSH and EXEC. For an overview of Remmina features, see herearchive.org.

Note there are two separate Debian packages:

  • remmina: the main GTK+ application.
  • remmina-plugins: a set of plugins to support various network protocols.

Install package(s) remmina.

A. Update the package lists and upgrade the systemarchive.org.

sudo apt update && sudo apt full-upgrade

B. Install the remmina package(s).

Using apt command line parameter --no-install-recommendsarchive.org is in most cases optional.

sudo apt install --no-install-recommends remmina

C. Done.

The procedure of installing package(s) remmina is complete.

If you are interested in using Remmina, please first search the forums for this topic: https://forums.whonix.org/search?q=remminaarchive.org

SSH into Whonix[edit]

Introduction[edit]

It is possible to install an SSH server on either Whonix-Gateway and/or Whonix-Workstation and make it accessible through an anonymous onion service.

SSH into Whonix-Gateway[edit]

1. Update the package lists and install necessary software.

sudo apt update

Install the openssh-server package.

sudo apt install --no-install-recommends openssh-server

2. Optionally harden SSH.

3. Make necessary Whonix-Gateway adjustments.

Open file /usr/local/etc/torrc.d/50_user.conf in a text editorarchive.org of your choice with sudoedit.

If you are using Qubes-Whonix, complete the following steps.

Qubes App Launcher (blue/grey "Q")Whonix-Gateway ProxyVM (commonly named sys-whonix)Tor User Config (Torrc)

If you are using a graphical Whonix-Gateway, complete the following steps.

Start MenuApplicationsSettings/usr/local/etc/torrc.d/50_user.conf

If you are using a terminal-only Whonix-Gateway, complete the following steps. sudoedit /usr/local/etc/torrc.d/50_user.conf

Add.

HiddenServiceDir /var/lib/tor/gateway_ssh_service/ HiddenServicePort 22 127.0.0.1:22 HiddenServiceVersion 3

Save.

4. Reload Tor.

After changing Tor configuration, Tor must be reloaded for changes to take effect.

Note: If Tor does not connect after completing all these steps, then a user mistake is the most likely explanation. Recheck /usr/local/etc/torrc.d/50_user.conf and repeat the steps outlined in the sections above. If Tor then connects successfully, all the necessary changes have been made.

If you are using Qubes-Whonix, complete the following steps.

Qubes App Launcher (blue/grey "Q")Whonix-Gateway ProxyVM (commonly named 'sys-whonix')Reload Tor

If you are using a graphical Whonix-Gateway, complete the following steps.

Start MenuApplicationsSettingsReload Tor

If you are using a terminal-only Whonix-Gateway, click HERE for instructions.

Complete the following steps.

Reload Tor.

sudo service tor@default reload

Check Tor's daemon status.

sudo service tor@default status

It should include a a message saying.

Active: active (running) since ...

In case of issues, try the following debugging steps.

Check Tor's config.

sudo -u debian-tor tor --verify-config

The output should be similar to the following.

Sep 17 17:40:41.416 [notice] Read configuration file "/usr/local/etc/torrc.d/50_user.conf".
Configuration was valid

5. Retrieve the Tor onion service url.

sudo cat /var/lib/tor/gateway_ssh_service/hostname

Reminder: Always backup the onion service key. This is necessary in order to restore it on another machine, on a newer Whonix-Gateway, after HDD/SSD failure, etc. Follow the instructions below to find its location; root permission is required to access it.

/var/lib/tor/workstation_ssh_service/hs_ed25519_secret_key

Qubes-Whonix

The following example shows how to copy the /var/lib/tor/workstation_ssh_service/hs_ed25519_secret_key from the sys-whonix VM to the vault VM (which should be started beforehand) using qvm-copyarchive.org. A dialog will appear asking for the destination VM.

sudo qvm-copy /var/lib/tor/workstation_ssh_service/hs_ed25519_secret_key

When the dialog appears asking to confirm, select vault. This copies the Tor onion service private key file to the QubesIncoming folder of the vault VM.

/home/user/QubesIncoming/sys-whonix/hs_ed25519_secret_key

Consider moving the file from the QubesIncoming folder to another preferred location.

Qubes VM Manager can be used to conveniently backup the vault and/or other VMs. Please refer to the Qubes backups documentation for necessary steps to accomplish that.

Non-Qubes-Whonix

See also:

Documentation for this is incomplete. Contributions are happily considered! See this for potential alternatives.

SSH into Whonix-Workstation[edit]

1. Update the package lists and install necessary software.

sudo apt update

Install the openssh-server package.

sudo apt install --no-install-recommends openssh-server

2. Optionally harden SSH.

3. Make necessary Whonix-Gateway adjustments.

Open file /usr/local/etc/torrc.d/50_user.conf in a text editorarchive.org of your choice with sudoedit.

If you are using Qubes-Whonix, complete the following steps.

Qubes App Launcher (blue/grey "Q")Whonix-Gateway ProxyVM (commonly named sys-whonix)Tor User Config (Torrc)

If you are using a graphical Whonix-Gateway, complete the following steps.

Start MenuApplicationsSettings/usr/local/etc/torrc.d/50_user.conf

If you are using a terminal-only Whonix-Gateway, complete the following steps. sudoedit /usr/local/etc/torrc.d/50_user.conf

Add.

Qubes-Whonix Note: Cannot use 10.152.152.11:22. See page Onion Services for /qubes-ip.

HiddenServiceDir /var/lib/tor/workstation_ssh_service/ HiddenServicePort 22 10.152.152.11:22 HiddenServiceVersion 3

Save.

4. Reload Tor.

Reload Tor.

After changing Tor configuration, Tor must be reloaded for changes to take effect.

Note: If Tor does not connect after completing all these steps, then a user mistake is the most likely explanation. Recheck /usr/local/etc/torrc.d/50_user.conf and repeat the steps outlined in the sections above. If Tor then connects successfully, all the necessary changes have been made.

If you are using Qubes-Whonix, complete the following steps.

Qubes App Launcher (blue/grey "Q")Whonix-Gateway ProxyVM (commonly named 'sys-whonix')Reload Tor

If you are using a graphical Whonix-Gateway, complete the following steps.

Start MenuApplicationsSettingsReload Tor

If you are using a terminal-only Whonix-Gateway, click HERE for instructions.

Complete the following steps.

Reload Tor.

sudo service tor@default reload

Check Tor's daemon status.

sudo service tor@default status

It should include a a message saying.

Active: active (running) since ...

In case of issues, try the following debugging steps.

Check Tor's config.

sudo -u debian-tor tor --verify-config

The output should be similar to the following.

Sep 17 17:40:41.416 [notice] Read configuration file "/usr/local/etc/torrc.d/50_user.conf".
Configuration was valid

5. Retrieve the Tor onion service url.

sudo cat /var/lib/tor/workstation_ssh_service/hostname

Reminder: Always backup the onion service key. This is necessary in order to restore it on another machine, on a newer Whonix-Gateway, after HDD/SSD failure, etc. Follow the instructions below to find its location; root permission is required to access it.

/var/lib/tor/workstation_ssh_service/hs_ed25519_secret_key

Qubes-Whonix

The following example shows how to copy the /var/lib/tor/workstation_ssh_service/hs_ed25519_secret_key from the sys-whonix VM to the vault VM (which should be started beforehand) using qvm-copyarchive.org. A dialog will appear asking for the destination VM.

sudo qvm-copy /var/lib/tor/workstation_ssh_service/hs_ed25519_secret_key

When the dialog appears asking to confirm, select vault. This copies the Tor onion service private key file to the QubesIncoming folder of the vault VM.

/home/user/QubesIncoming/sys-whonix/hs_ed25519_secret_key

Consider moving the file from the QubesIncoming folder to another preferred location.

Qubes VM Manager can be used to conveniently backup the vault and/or other VMs. Please refer to the Qubes backups documentation for necessary steps to accomplish that.

Non-Qubes-Whonix

See also:

Documentation for this is incomplete. Contributions are happily considered! See this for potential alternatives.

6. Adjust Whonix-Workstation firewall settings.

Modify Whonix-Workstation User Firewall Settings

Note: If no changes have yet been made to Whonix Firewall Settings, then the Whonix User Firewall Settings File /etc/whonix_firewall.d/50_user.conf appears empty (because it does not exist). This is expected.

If using Qubes-Whonix, complete these steps.
In Whonix-Workstation App Qube. Make sure folder /usr/local/etc/whonix_firewall.d exists.

sudo mkdir -p /usr/local/etc/whonix_firewall.d

Qubes App Launcher (blue/grey "Q")Whonix-Workstation App Qube (commonly called anon-whonix)Whonix User Firewall Settings

If using a graphical Whonix-Workstation, complete these steps.

Start MenuApplicationsSystemUser Firewall Settings

If using a terminal-only Whonix-Workstation, complete these steps.

Open file /usr/local/etc/whonix_firewall.d/50_user.conf with root rights.

sudoedit /usr/local/etc/whonix_firewall.d/50_user.conf

For more help, press on Expand on the right.

Note: This is for informational purposes only! Do not edit /etc/whonix_firewall.d/30_whonix_workstation_default.conf.

The Whonix Global Firewall Settings File /etc/whonix_firewall.d/30_whonix_workstation_default.conf contains default settings and explanatory comments about their purpose. By default, the file is opened read-only and is not meant to be directly edited. Below, it is recommended to open the file without root rights. The file contains an explanatory comment on how to change firewall settings.

## Please use "/etc/whonix_firewall.d/50_user.conf" for your custom configuration,
## which will override the defaults found here. When {{project_name_short}} is updated, this
## file may be overwritten.

Also see: Whonix modular flexible .d style configuration folders.

To view the file, follow these instructions.

If using Qubes-Whonix, complete these steps.

Qubes App Launcher (blue/grey "Q")Template: whonix-workstation-17Whonix Global Firewall Settings

If using a graphical Whonix-Workstation, complete these steps.

Start MenuApplicationsSettingsGlobal Firewall Settings

If using a terminal-only Whonix-Workstation, complete these steps.

In Whonix-Workstation, open the whonix_firewall configuration file in an editor. nano /etc/whonix_firewall.d/30_whonix_workstation_default.conf

Add.

EXTERNAL_OPEN_PORTS+=" 22 "

Save.

7. Reload the firewall.

Reload Whonix-Workstation Firewall.

If you are using Qubes-Whonix, complete the following steps.

Qubes App Launcher (blue/grey "Q")Whonix-Workstation App Qube (commonly named anon-whonix)Reload Whonix Firewall

If you are using a graphical Whonix-Workstation, complete the following steps.

Start MenuApplicationsSystemReload Whonix Firewall

If you are using a terminal-only Whonix-Workstation, run. sudo whonix_firewall

Graphical[edit]

Introduction[edit]

It is possible to install a VNC server on either Whonix-Gateway and/or Whonix-Workstation and make it accessible through an anonymous onion service.

x2go[edit]

Installation[edit]

1. Set up SSH first as per above chapters.

This is because x2go uses SSH. x2go might be incompatible with SSH hardening. It has been reported that x2go is incompatible with password protected SSH keys but this was not investigated further or reported upstream.

2. Update the package lists and install necessary software.

Either on Whonix-Gateway or Whonix-Workstation, depending on where incoming x2go connection should be accepted.

sudo apt update

Install the x2goserver package.

sudo apt install --no-install-recommends x2goserver

Usage[edit]

In a Whonix-Workstation (remote-support-provider VM). [1]

1)

Install package(s) x2goclient.

A. Update the package lists and upgrade the systemarchive.org.

sudo apt update && sudo apt full-upgrade

B. Install the x2goclient package(s).

Using apt command line parameter --no-install-recommendsarchive.org is in most cases optional.

sudo apt install --no-install-recommends x2goclient

C. Done.

The procedure of installing package(s) x2goclient is complete.

2) Start x2goclient.

As user. Run x2goclient.

  • host: the onion v3 domain
  • login: the user name such as user
  • password: the user login password such as changeme
  • session type: connect to local desktop
  • media -> disable client side printing support
  • media -> disable sound support
  • settings for better performance
    • connection -> connection speed -> WAN
    • connection -> image quality 0
    • connection -> method -> 8-jpeg
    • feel free to experiment with these settings
  • OK
  • Click on the newly setup connection
  • OK

Alternatively session type terminal could be used.

Test Results[edit]

Using Non-Qubes-Whonix. All times are created with an external stopwatch and should have +/- 2 seconds human caused inaccuracy.

  • keypress delay: 2 seconds
  • maximize xfce4-terminal-emulator window: 1.5 seconds
  • cd /etc && ls -la: 2 seconds
  • clock in systray (shows seconds) update: every 1 or 2 seconds
  • start thunar: 5 seconds

Using Qubes / Qubes-Whonix is a lot slower, has additional challenges and is still under development, see Dev/Qubes_Remote_Support.

Qubes - SSH or VNC into Qubes dom0[edit]

Introduction[edit]

Encrypted, authenticated SSH or VNC into Qubes dom0 over an authenticated Tor onion v3 service.

Design [2]:

  • Encrypted. [3]
  • Authenticated. [4]
  • Over Tor.
  • Implemented using an authenticated Tor onion v3 service.
  • Even if Whonix on qubes-remote-support-receiver machine was compromised, the attacker will not be able to access dom0. [5]
  • The package will not be installed by default.

  • The design requires explicit connection initiation by the user (no any open ports, extra network connections etc before that point). And when the user initiate the connection, it requires sharing a code word with the remote party to be able to connect.

  • No open ports required.
  • No router settings changes required.
  • Works behind NAT.
  • Works over mobile networks (3G, 4G, 5G).

Instructions:

  • qubes-remote-support-receiver have to be applied by the person who intents to receive remote support.
  • qubes-remote-support-provider have to be applied by the person who intents to provide remote support.

qubes-remote-support-receiver[edit]

Not available for Qubes R4.0! Only available on Qubes R4.1 (and above).

Security advice: Giving a third party remote support access is a very delicate permission. As with any remote support permission, the qubes-remote-support-provider could persistently compromise the qubes-remote-support-receiver with malware without the user having a chance to notice that. Learn The Importance of a Malware Free System.

1) Qubes R4.1 dependency installation.

Install package qubes-remote-support-receiver-dom0 in Qubes dom0. [6] [7]

sudo qubes-dom0-update qubes-remote-support-receiver-dom0

2) Run the qubes-remote-support-receiver-start command line utility.

qubes-remote-support-receiver-start

Will show something like this (example):

wormhole_code: 9-support-concert

3) Notification.

Tell the wormhole code (for example 9-support-concert) to the person you would like to receive Qubes remote support from, i.e. the qubes-remote-support-provider.

Note: not 9-support-concert. The actual code as shown in terminal / graphical user interface.

4) To check status of remote support.

qubes-remote-support-receiver-status

5) To terminate remote support.

qubes-remote-support-receiver-stop

qubes-remote-support-provider[edit]

1) Dependency installation.

Start whonix-workstation-17 Template.

(The latter package x2goclient can be omitted from installation connecting to qubes-remote-support-receiver use of x2go (VNC) is unwanted.)

Install package(s) openssh-client x2goclient.

A. Update the package lists and upgrade the systemarchive.org.

sudo apt update && sudo apt full-upgrade

B. Install the openssh-client x2goclient package(s).

Using apt command line parameter --no-install-recommendsarchive.org is in most cases optional.

sudo apt install --no-install-recommends openssh-client x2goclient

C. Done.

The procedure of installing package(s) openssh-client x2goclient is complete.

Shutdown whonix-workstation-17 Template.

2) Start virtual machine (VM).

Open a whonix-workstation-17 based VM. Recommended but optional: DispVM. This will be refereed to as qubes-remote-support-provider VM.

3) Run qubes-remote-support-provider script in qubes-remote-support-provider VM.

qubes-remote-support-provider

It is an interactive script. Read what it says. Continue by pressing enter.

4) When it says:

INFO: Install authenticated Tor onion v3 service private key with the following command in sys-whonix.
sudo sourcefile=~/QubesIncoming/disp4522/1.auth_private anon-server-to-client-install

Do as instructed in sys-whonix VM. Do not copy the command from here. Copy the command from qubes-remote-support-provider VM script output, then paste and run in sys-whonix VM. Then press enter to continue in qubes-remote-support-provider VM.

5) Done.

Should now be connected by SSH.

6) Optional: Connect by graphical remote support (x2go).

As per instructions below.

x2goclient[edit]

Broken until upstream fix for issue x2goagent 3.5.99.26 crashes on connectarchive.org flows to Qubes R4.1 dom0.

In a Whonix-Workstation (remote-support-provider VM).

1) Start x2goclient.

As user. Run x2goclient.

2) x2goclient settings

  • session tab
    • host: the onion v3 domain
    • enable Try auto login (via SSH agent or default SSH key)
    • session type: connect to local desktop
  • media tab
    • media -> disable client side printing support
    • media -> disable sound support
  • connection tab
    • These are optional settings for better performance. Feel free to experiment with these settings.
    • connection -> connection speed -> WAN
    • connection -> image quality 0
    • connection -> method -> 8-jpeg
  • OK
  • Click on the newly setup connection
  • OK

Alternatively session type terminal could be used.

If you can only see a black screen, the the desktop might be locked (xscreensaver). Any mouse movement or any keypress should prompt for password.

Not required:

  • login: not required
  • password: not required

printout[edit]

Qubes Remote Support Receiver[edit]

qubes-remote-support-receiver-start
INFO: Starting Qubes Remote Support Receiver.
INFO: This tool is supposed to be run by those who wish to receive remote support.
INFO: Setting up... This will take a moment...
INFO: Remote support archive file '/tmp/tmp.Yfv3ehL6ZJ/remote-support-keys.tar.gz' was successfully created.
INFO: (That file allows a Qubes Remote Support Provider to connect to this machine.)
INFO: (No need to do anything with that file.)
INFO: Starting the file transfer tool magic-wormhole... This will take a moment...
INFO: File transfer too magic-wormhole successfully started.
INFO: The next line will show a wormhole code phrase. Send the code to the Qubes Remote Support Provider. Once the the Qubes Remote Support Provider acknowledged receipt, just wait.
wormhole_code: 9-one-two-three-four
INFO: The Qubes Remote Support Provider successfully received the remote support archive file and is now able to establish remote support.
INFO: This can take up to 10 minutes.

INFO: Should you wish to stop this Qubes Remote Support Session, please run:
qubes-remote-support-receiver-stop

INFO: This tool will exit now and there is nothing else to do besides waiting.
INFO: Success.
qubes-remote-support-receiver-status
● sshd.service - OpenSSH server daemon
     Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; vendor preset: disabled)
     Active: active (running) since Sat 2021-02-13 06:49:51 EST; 3 weeks 3 days ago
[...]
Hint: Some lines were ellipsized, use -l to show in full.
INFO: /etc/qubes-rpc/policy/qubes.ConnectTCP+22 looks OK.
qvm-check: {{project_name_gateway_vm}}: running
INFO: VM '{{project_name_gateway_vm}}' already running, ok.
___ qubes-whonix-remote-support.service - Qubes-Whonix Remote Support
   Loaded: loaded (/lib/systemd/system/qubes-whonix-remote-support.service; disabled; vendor preset: disabled)
   Active: active (running) since Tue 2021-03-09 13:51:30 UTC; 9min ago
[...]
___ tor@default.service - Anonymizing overlay network for TCP
   Loaded: loaded (/lib/systemd/system/tor@default.service; enabled-runtime; vendor preset: enabled)
[...]
   Active: active (running) since Tue 2021-03-09 13:43:23 UTC; 17min ago
[...]
INFO: Success.
qubes-remote-support-receiver-stop
INFO: sshd was previously running, therefore not stopping it, ok.
INFO: VM '{{project_name_gateway_vm}}' already running, ok.
INFO: Success, remote support received has been turned off.

Qubes Remote Support Provider[edit]

qubes-remote-support-provider
INFO: Starting Qubes Remote Support Provider.
INFO: This tool is supposed to be run by those who wish to provide remote support.
INFO: Setting up... This will take a moment...
INFO: Ask the remote support receiver for the wormhole code phrase and enter it below.
Enter receive wormhole code: 9-one-two-three-four
 (note: you can use <Tab> to complete words)
Receiving file (814 Bytes) into: remote-support-keys.tar.gz
ok? (y/N): y
Receiving (->relay:tcp:magic-wormhole-transit.debian.net:4001)..
100%|████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████| 814/814 [00:00<00:00, 3.82MB/s]
Received file written to remote-support-keys.tar.gz
INFO: Success, received remote support archive file '/tmp/tmp.ZTe9baxU6Z/remote-support-keys.tar.gz'.
INFO: (That file allows a Qubes Remote Support Provider to connect to this machine.)
INFO: (No need to do anything with that file.)
INFO: Setting up... This will take a moment...

Success. Please continue as instructed below.

INFO: To avoid confusion, it is advised your delete folder ~/QubesIncoming in {{project_name_gateway_vm}} if it exists. In most cases no such folder exists.
INFO: If there is nothing you need to backup, you could run the following command in {{project_name_gateway_vm}}:

rm -rf ~/QubesIncoming

INFO: When done, press enter to continue.


INFO: Will ask to copy 1.auth_private to {{project_name_gateway_vm}}.
INFO: When Qubes dom0 asks, answer to copy to {{project_name_gateway_vm}}.
INFO: Press enter to continue.


sent 0/1 KB

INFO: Install authenticated Tor onion v3 service private key by running the following command in {{project_name_gateway_vm}}:

sudo sourcefile=~/QubesIncoming/disp2887/1.auth_private anon-server-to-client-install

INFO: When done, press enter to continue.


INFO: Do you want to SSH to 'xxx.onion'?
INFO: Press enter to continue.


INFO: Trying SSH...
INFO: Will keep trying to run the following command...
ssh 'xxx.onion'
INFO: This can take up to 10 minutes.
Last login: Tue Mar  9 08:49:28 2021 from xx.xx.xx.x
[user@dom0 ~]$

Test Results[edit]

  • Running a simple command such as ls -la takes 1 second until results are drawn.
  • There is an 1 seconds delay between a keypress on inside remote-support-provider VM until it gets visible in the remote terminal.
  • Click Xfce start menu: 2 seconds
  • clock in systray (shows seconds) update: every 1 or 2 seconds
  • There is a bug where I have no idea if caused by Qubes R4.1 testing version or x2go or a combination of it. When pressing any key it sometimes happen that this key is auto-repeat "jammed". I.e. "a" becomes "aaaaaaaaaaaaaaa" (no exact counting).

See Also[edit]

Help Wanted[edit]

Please contribute by helping to create full working instructions in Whonix! See: add user documentation for Remote Administration, Keystroke Fingerprinting, Stylometryarchive.org.

Future Research[edit]

[1] comparing vnc, nx(x2go) and spice. VNC sends the least amount of data. nx has a stable perf irrelevant of bandwidth conditions however one disadvantage I came across was it is heavily tied to X11 and therefore not future proof. https://bbs.archlinux.org/viewtopic.php?id=225765archive.org

[1] https://www.diva-portal.org/smash/get/diva2:530960/FULLTEXT01.pdfarchive.org

VNC perf depends heavily on implementation details. TigerVNC is better than realvnc, but Remmina is commented to be better than tiger. "A 2010 reviewer found the TigerVNC product "much faster than Vinagre https://en.wikipedia.org/wiki/Vinagrearchive.org but not quite as responsive as Remmina https://en.wikipedia.org/wiki/Remminaarchive.org https://en.wikipedia.org/wiki/TigerVNCarchive.org "

Tiger can be further optimized for constrained environments by ratcheting up the compression and lowering the jpeg quality. NB turbo isn't in Debian and it seems geared towards 3D usage. https://turbovnc.org/About/TigerVNCarchive.org

Footnotes[edit]

  1. Or any other system with transparent torification. It cannot be easily made to work using socksifier torsocks.
  2. Thanks to encryption provided by Tor onion v3 and SSH.
  3. Thanks to authentication provided by Tor onion v3, onion authentication and SSH.
  4. Thanks to encryption/authentication provided by SSH.

    Public/private keys for SSH are generated in Qubes dom0 by qubes-remote-support-receiver. At no point, any Whonix VM on qubes-remote-support-receiver has access to any SSH keys.

    SSH keys are transferred from qubes-remote-support-receiver to qubes-remote-support-provider using magic-wormhole tool over Tor.
  5. https://github.com/QubesOS/qubes-remote-supportarchive.org

We believe security software like Whonix needs to remain open source and independent. Would you help sustain and grow the project? Learn more about our 12 year success story and maybe DONATE!