0

I would like you to help me with the following problem. I will try to give as many details as possible.

I recently installed a vnc server on a Centos8 virtual machine. I have done all the configuration steps, which are in this file, (which by the way is the one that vnc recommends using, since I think vnc was updated and the configuration method is not the same as before). Once this is done, the server is working without problem. (apparently) The problem arises when I want to connect from another virtual machine (Fedora), the server rejects the connection and gives the following error:

IMAGE

In the server I execute the following instruction

vncviewer localhost:5901

I have consulted in some forums, and it is mentioned that it is a firewall problem that does not let the communication pass. So disable the firewall and Selinux)on both virtual machines, however the problem persists. I know that the server is running correctly, because I get the following output.

[root@localhost andres]# systemctl status vncserver@:1
● vncserver@:1.service - Remote desktop service (VNC)
   Loaded: loaded (/usr/lib/systemd/system/vncserver@.service; enabled; vendor preset:>
   Active: active (running) since Mon 2021-03-01 13:21:07 EST; 1h 7min ago
  Process: 978 ExecStart=/usr/libexec/vncsession-start :1 (code=exited, status=0/SUCCE>
 Main PID: 994 (vncsession)
    Tasks: 1 (limit: 11260)
   Memory: 1.5M
   CGroup: /system.slice/system-vncserver.slice/vncserver@:1.service
           ‣ 994 /usr/sbin/vncsession andres :1

I also have these ports assigned, which tell me that the server is listening

[root@localhost andres]# netstat -tunlp | grep 5901
tcp        0      0 127.0.0.1:5901          0.0.0.0:*               LISTEN      1381/Xvnc           
tcp6       0      0 ::1:5901                :::*                    LISTEN      1381/Xvnc

Maybe it looks like a duplicate question from the following forum. And indeed it is, I just can't find a relation, since vnc has been updated and the configuration is not the same (that is, to start the server, I can no longer put the command "vncserver"), and I assume that the solution will not be the same

  • 1
    in the file you referred to, I see in the "Limitations" section that you cannot connect when the user is already logged in, so I suspect trying to connect locally won't ever work, so try from the outside. – strobelight Mar 03 '21 at 21:28

1 Answers1

0

I suspect you still have a firewall running or configured use of localhost but didn't use a tunnel. In my steps below, I show how to open the vnc ports and use a tunnel.

I'm not sure which vnc you installed, but with tigervnc, here's what I did:

  • as root, edit /etc/tigervnc/vncserver-config-defaults and add session=gnome at the bottom (I use gnome). If you uncomment localhost you'll need to establish a secure tunnel. If you want to restrict which IP accepts connections, add a line interface=x.x.x.x where x.x.x.x is an IP for your host.
  • as root, edit /etc/tigervnc/vncserver.users and add display=user for each user allowed to connect (root is not recommended); in my case :1=user1, corresponding to vnc port 5901.
  • as the user, create a password, vncpasswd (this will be the password to use with the client)
  • as root, start vnc for the user, systemctl start vncserver@:1
  • as root, open the vnc ports: firewall-cmd --permanent --add-port=5901-5999/tcp
  • restart the firewall: systemctl restart firewalld
  • find your IP: ip addr | grep inet (don't pick localhost, nor your gateway, in my case 192.168.122.40
  • log out

At this point, a vnc server is running listening on port 5901 corresponding to display :1 for the user, user1 in my case.

You'll need to install a vnc viewer on some other VM or even your local system.

If you uncommented localhost in the vncserver-config-defaults file, then start a tunnel from your local machine ssh -L 5901:localhost:5901 user@server (exiting this connection will close the tunnel, if you always want it open,ssh -N -f -L 5901:localhost:5901 user@server). Open another window on your local machine to run vncviewer from command line.

Start the vncviewer, and enter the IP:port in the server box, in my case 192.168.122.40:5901 and click Connect. If I had started a tunnel, the server would be localhost:5901.

When prompted for the password, enter the password you supplied to vncpasswd. This establishes the connection.

At this point, your gnome session is up and viewable. You may have to press the Enter/Return key to have it prompt for credentials.

When you log out, the vncserver will most likely also close, but I didn't research further how to get the vncserver automatically restarted for the user.

strobelight
  • 751
  • 3
  • 13
  • I'm not sure where to put the IP address so the server won't listen on localhost, the only relationship that I find is in the `/etc/tigervnc/vncserver-config-defaults` file. Should I change localhost parameter to the ip of my computer? I have the file configured like this:`session=gnome securitytypes=vncauth,tlsvnc desktop=sandbox geometry=800x600 localhost alwaysshared` – Andres Valarezo Mar 04 '21 at 05:15
  • I've updated my answer when `localhost` is uncommented. – strobelight Mar 04 '21 at 12:09
  • please accept the answer if no further comments I need to address. – strobelight Mar 05 '21 at 14:33
  • It worked perfect for me, thank you very much, it seems that I had forgotten to do the SSH tunnel. One final question. It is assumed if I change "localhost", it only serves to indicate which IP addresses can connect to the computer, right? – Andres Valarezo Mar 07 '21 at 23:36
  • I wanted to comment that I made the tunnel with this instruction, I don't know why the instruction provided in the answer didn't work for me. `ssh -L 5901:localhost:5901 -N -f -l ` – Andres Valarezo Mar 07 '21 at 23:43
  • I've adjusted my answer regarding the `-N -f` options (I was just doing a simple test). Regarding your comment about "localhost", it has nothing to do with which IPs have access to the computer. I believe any computer can establish a tunnel to the computer running the VNC server. Those connections however do need the credentials to do so. – strobelight Mar 08 '21 at 14:16