If you did not migrate your account yet, visit https://idp-portal-info.suse.com/
User:Tsu2/remote administration VNC
- 1 openSUSE Remote Administration (VNC)
- 1.1 Preamble
- 1.2 Brief architectural description
- 1.3 Basic info
- 1.4 Prerequisites which may not be configured by default
- 1.5 Security
- 1.6 Types of VNC server configurations
- 1.8 Firewalld
- 1.9 Intentionally uncovered topics
- 1.10 VNC Clients
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
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).
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
- 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.
- 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.
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.
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
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.
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
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.
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
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
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.
The novnc package provides support for VNC connections using a web browser.
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.
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