The wikis are now using the new authentication system.
If you did not migrate your account yet, visit https://idp-portal-info.suse.com/

User:Tsu2/remote administration VNC

Jump to: navigation, search

openSUSE Remote Administration (VNC)

This article changes the usual order of a few things because it likely makes more sense to either set these things up beforehand or keep them in mind as you perform main configurations

Preamble

TMI;DR
Preamble

Brief architectural description

VNC is a cross-platform application to view remote graphical desktops,
There are numerous alternatives including passing X over SSH and applications that use the RDP protocol.
TigerVNC is the version of VNC installed on openSUSE, which is the standard for use in Enterprises. Other VNC flavors may not support advanced features such as various authentication methods.
VNC supports the XDMCP protocol for *NIX including Linux, but also generally supports Remote Frame Buffer (RFB) which is supported on all platforms.
Windows machines do not support XDMCP, so connecting to or from a Windows machine is supported only by RFB.
XDMCP supports numerous authentication options
RFB supports only a password and nothing else.
On Linux, regardless whether the Server is headless or is configured for a User to logon locally, at least a Display Manager and Window Manager must be installed on the Server.
Where an X server is implemented (legacy and required for Xorg but optional for Wayland today), the X server must be running. If a systemd socket service is implemented instead of an X server, the service must be running (most often enabled so that it automatically starts on boot)
When connecting to a Linux VNC server, the client is authenticated by and connects to any available Display Manager (client normally can choose if more than one is available).

ToDo Inspect and understand use of X Windows protocol(?) for actual transmission of graphical data. May mean that XDMCP is used only for initiation and not thereafter.
XDMCP may require use of both TCP and UDP so may not be supported by SSH tunneling which may support only TCP

Basic info

- All standard installations(excluding corner implementations like JeOS) install Tigernvnc (server and client) and ssh inaries by default, but are unconfigured so for instance won't have any systemd Unit files installed. This will mean that vnc commands will work out of the box but lack the organized and partial setup of a proper installation. This article assumes a full openSUSE VNC installation, not the bare bones packages installed by default.

-(May not be explained adequately in openSUSE documentation but can be found in Tigervnc and vnc documentation) The VNC DisplayID and ConnectionID are entirely separate identifiers, but for simplicity are normally enumerated the same. Although this is not normally an issue using pre-configured connections, care must be taken when creating a new, completely original connection.

- openSUSE VNC server installation only opens the first standard port for regular VNC and javascript, additional firewall ports must be opened manually should VNC be configured for additional ports.

- Passwords for logging into any VNC session only initiates the successful VNC connection, without further configuration the session is uncencrypted and text is likely exchanged as clear text. See "Encryption" section below to encrypt the session.



Prerequisites which may not be configured by default

By default, a DM that supports XMCCP is required to support "better" logon security. SDDM which is the default DM for KDE/Plasma is notorious for its lack of VNC support today.... Although Wikipedia claims SDDM supports XDMCP which would imply VNC support.


Security

All openSUSE DMs installed from openSUSE repositories which support XMCCP are configured to enabled to support XMCCP by default with its full array of security options. Beware that "all" options include non-secure. If you want to ensure secure connections, non-secure options need to be removed and you may want to edit using YaST (or edit the /etc/sysconfig/ files directly). Naturally, if non-secure options are removed but no secure option is set up correctly, this creates a troubeshooting issue.

Unlike other distros which require manual edits to DM configuration files, openSUSE YaST is a "one tool for all" solution. Open YaST > /etc/sysconfig editor Drill down Desktop > Display Manager > Remote Connecctions

Besides encrypting the VNC connection itself, you can also wrap the connection in an SSL tunnel as an additional or replacement method.
Easiest way to install and configure the SSL server daemon is to select the option in the original installation (bottom of the Installation Summary screen).
If you didn't simply check the two boxes during your original system installation and need to set up and configure your SSH daemon or you need to maintain/manage your SSH Server, information can be found in the MAN pages and the LEAP documenation. More advanced configurations, particulrly regarding security are at the end of the following article.

https://doc.opensuse.org/documentation/leap/security/html/book.security/cha-ssh.html#sec-ssh-sshdserver

Better security wrapping VNC

Configure VNC to accept only localhost connection (-localhost) Create SSH tunnel that specifies forwarding from the standard vnc port restricted to localhost to a port of your choice that isn't restricted

ssh 10.10.1.1 -L 9901:localhost:5901

Now you can invoke the client to connect to the custom port on localhost which would then connect to the Server's localhost interface with VNC port

vncviewer localhost:9901



Types of VNC server configurations

First, a short preamble. VNC is extremely flexible, and today there are numerous ways to implement VNC in user or system modes, instantiate and with different default configurations. I am sure that imaginative readers might conceive of other, new methods beyond what is described here.

Multi-User(Shared)

The LEAP documentation calls this "Shared" but only the socket-based service is shared... Every user connection spawns a new, individual VNC server instance. This is not a shared Desktop and multiple Users cannot login to the same session. In this configuration, default settings for display and networking are identical for all. Although I do not see described anywhere, I assume that copies of the service can be configured for different ports which can each present different default settings.
Plus - Unlimited number of connections without complex configuration
Minus - Every instance's default configuration is the same

Like in LEAP 42.x configuration file, only one socket is enabled by default and two are reserved. You can also create additional configurations by defining new socket service files.

systemctl list-units --all xvnc
systemctl list-units --all xvnchttpd

systemctl enable/disable xvnc.socket
systemctl start/stop/restart xvnc.socket

If parameters within a particular socket is modified, you must "reload" the socket. Not needed for overall enable/disable or start/stop/restart the service. If you modify more than one service, you can reload all systemd services by not specifying a specific service.

systemctl reload xvnc.socket



User/System Mode

Configurations are pre-configured on the Server, and each configuration is associated with a TCP/IP port number which is normally associated with its own display
Plus - Fine grained default configuration by default
Supports persistent connections (logoff and leave the session running)
Minus - Only one VNC session which can be shared or not per port/display

Initiated by vncserver command
Interactive logons by common password
Read-Only logons by different common password

Although each type of persistent VNC session can be manually configured by command line attributes or GUI, configurations can also be defined within the following file.

$HOME/.vnc/xstartup

By default, the Window Manager used in the VNC session will be the same as the Host system's but a different WM can be defined, for example

WINDOWMANAGER=icewm vncserver -geometry 1024x768

start

The following starts a session on port 5903 (so as not to step on ports possibly used by one-time configurations on 5900, 5901 and 5902)

vncserver -alwaysshared -port 5903 -geometry 1024x768 -depth 16

Running this command the first time will prompt for to provide the common interactive logon password and optional read-only login password.

shutdown (the persistent sesssion)

Anyone logged in interactively can shutdown using any normal methods (Desktop shutdown, systemctl poweroff, shutdown -h now)

If logged on to the HostOS, the session can be killed

vncserver kill :3

VNC Manager

Set up by YaST, this is a graphical way to set up and configure your VNC connections. Supports both the previous types of connections
Plus - Easy, graphical setup
Minus - Many more steps required for configuration

Open and run
YaST > Network Services > Remote Administration (VNC)

Activate Allow Remote Administration With Session Management.
Activate Enable access using a web browser if you plan to access the VNC session in a Web browser window. Open ports as needed.

Once configured as described above, connect using a VNC client.
After logging in, click on the VNC icon in the system tray and select "VNC session" and continue to configure the session's parameters.

Javascript Client support (Web Browser)

The novnc package provides support for VNC connections using a web browser.
Since approx 2013, the web client runs entirely in Javascript, not Java. Despite numerous references even in the MAN pages to Java, no Sun/Oracle compiled Java runs anywhere, this is a stub proxy running in javascript which translates vnc data from the VNC Server to TCP/IP data on the network and displays as a web page running javascript on the client.


Firewalld

Firewalld is the current default firewall manager installed and used in openSUSE. If another firewall manager is used, follow those instructions to open ports as needed.

Configure firewalld to open more ports for your configured network connections, by default only the first is configured and enabled for both regular and javascript connections

Edit
/usr/lib/firewalld/services/Tigervnc.xml
/usr/lib/firewalld/services/Tigernvnc-https.xml


Notes

Intentionally uncovered topics

x0vncserver - Should not be used, is less performant than using the Xvnc binary which should be standard

No supporting files in the VNC man pages exist in an openSUSE VNC installation.

Notable configuration files
/etc/X11/xorg.conf.d/10-libvnc.conf


VNC Clients

Remina
VNC client