Your question was a good push for me to review current openSUSE documentation…
It looks like at least for LEAP 15 (and likely Tumbleweed) the architecture has radically changed, and I’m not sure for the better.
Bottom line to answer your question is that configurations don’t seem to be laid out in an easy to view configuration file like before, and now configurations are associated with individual User accounts.
The relevant documentation
But, I found that woefully insufficient… and the new architecture is immensely large and complex.
.I’ve not set up multiple configurations, so my “understandings” after the following install steps are part understanding, part speculation, part observation of the available info.
Probably the most important info I’d direct you to is the ending section of the xvnc MAN pages, but that may not make sense until you wade through the LEAP documentation, help file and earlier parts of the MAN pages. Wow. Nothing is that simple anymore unless you bend to just use defaults…
After identifying the likely design basics,
I recommend the following…
Install Remote Administration (VNC) using YaST.
It seems that xinetd (and an xorg x server) is no longer required and the YaST module integrates with firewalld opening up the VNC default VNC ports for the VNC client and Java web client.
Test whether your VNC server is running, notice that you have to specify xvnc.socket. Unlike previous openSUSE, xinetd is no more. The king is dead, long live the king!(Well, not really. See below)
systemctl status xvnc.socket
- Now, I don’t yet see a way to list all existing VNC configurations, only that of 6 existing configurations that only 2 are enabled(one VNC client and one Java client). That’s not too helpful. Interestingly, you will also find the following xvnc service which at the moment I suspect is dynamically created.
OK, now my current observations which are subject to change…
Whereas prior VNC servers were deployed by xorg xservers, now that’s not the case but optionally available. As a socket type service, VNC server is supposed to be actively listening but not actually running. When a client connects, VNC server manually starts up and negotiates a connection with the client. Since multiple VNC clients might connect simultaneously on the same initial port, a new port is negotiated for each client… Sort of how FTP secondary connections is done. Also, if you don’t want the xvnc app to have to start up on demand, supposedly it’s possible to install and run the xinetd as a service like previous VNC versions.
It seems that client configuration files are no longer supported (that I can find).
Instead, the new design seems to be based not on generic configurations but a configuration associated with each User (Boy, I bet that’ll go over well in larger deployments supporting many Users… Not!)
User authentication can be set up a number of different ways, it looks like openSUSE is likely set up to support configured system Users (because of the installed pam module).
Based on my documentation read, that’s your likely road to configuring what you want…
Whether you use a Password file (I might recommend that so the VNC user might not automatically have full locally logged in permissions) or some other form of authentication, you’ll need to configure settings specific to that User.
Other minor technical thing to look at… Since xvnc now can be accessed both over the network and locally by sockets, I guess that both a network socket as well as Unix socket is now used? Or, something new?
As for your other question about X over ssh, I’m pretty sure nothing there has changed… It’s no longer supported in a default VNC now that VNC has deprecated xinetd somewhat… So, you’ll need to install xinetd for X over SSH.