VNC Viewer: how to use, installation and settings. Connecting to a remote computer via VNC

To install, we need a server or a remote computer, a local computer with a VNC client with support for connecting via an SSH tunnel. For Windows users, we recommend RealVNC, UltraVNC or TightVNC. On Mac OS you can use standard utility Screen Sharing, or install other VNC applications in the app store. Linux users have more wide choose programs such as krdc, vinagre, TightVNC, RealVNC, Remmina, etc.

Installing Desktop Environment and VNC Server

By default, Ubuntu 16.04 images do not have a graphical desktop shell and a VNC server, which must be installed additionally. First, let's install the packages latest version Xfce desktop environment and the TightVNC package from the Ubuntu repositories.

On the ordered server, install the Xfce and TightVNC packages.

$ sudo apt install xfce4 xfce4-goodies tightvncserver

To complete initial setup VNC server and after installing it, use the vncserver command to set a strong password.

$vncserver

You will be prompted to enter and confirm your password and specify a viewing password. Users using a browsing password will not be able to do anything with the keyboard and mouse on a VNC machine. This can be useful for demonstrating something on your VNC server to other people.

Performance vncserver completes VNC installations creating default configuration files, as well as creating information for connecting to our server. After installing these packages, you can configure the server.

Setting up a VNC server

First, let's specify the commands that the VNC server should execute upon startup. These commands are specified in the configuration file xstartup in a subdirectory .vnc yours home directory. The startup script was created while the command was running vncserver in the previous step, now we will change some commands to work with Xfce.

When you first start VNC, it launches a default server instance on port 5901. This port is called the display port ( display port), and in VNC it has the designation: 1. VNC can launch many instances on other ports, for example, :2, :3, and so on. When working with VNC servers, remember that display port number:X runs on port 5900 X.

Since we are going to make changes to the VNC server configuration, we first need to stop the server instance running on port 5901.

$ vncserver -kill:1

The output should look similar, down to the process ID:

Conclusion
Killing Xtightvnc process ID 17648

Before making changes to new file xstartup, let's do it backup copy source file.

$ mv ~/.vnc/xstartup ~/.vnc/xstartup.bak

Now let's create a new xstartup file using nano or another text editor.

$ nano ~/.vnc/xstartup

Paste these commands into a file to run them automatically when you start or restart the VNC server, then save and close the file.

~/.vnc/xstartup
#!/bin/bash
xrdb $HOME/.Xresources
startxfce4&

First file command xrdb $HOME/.Xresources tells the VNC GUI framework to use a custom .Xresources file. File .Xresources saves certain custom settings desktop, for example terminal colors, cursor theme, font rendering. The second command instructs the server to launch Xfce, which allows you to comfortably manage your server.

In order for the VNC server to use these settings, we will make the file executable.

$ sudo chmod x ~/.vnc/xstartup

Now let's restart the VNC server.

$vncserver

The server should restart and display something similar to the console:

Conclusion
New "X" desktop is your_server_name.com:1
Starting applications specified in /home/sammy/.vnc/xstartup
Log file is /home/sammy/.vnc/liniverse.com:1.log

Testing the VNC desktop

First, let's create an SSH connection to local machine to establish a secure connection with VNC. You can do this using a terminal on Linux or OS X with the following command. Don't forget to replace username And server_ip_address to your username with sudo rights and the IP address of your server.

$ ssh -L 5901:127.0.0.1:5901 -N -f -l username server_ip_address

If you are using graphical SSH client, for example PuTTY, set server_ip_address as the connection IP address, and also set localhost:5901 as a forwarded port in your client's SSH connection settings.

Next, you can use your VNC client to establish a connection to the VNC server on localhost:5901 . You will be prompted to authenticate. Use the password you set in the first step.

Once the connection is successfully established, you will see the default Xfce desktop. It should look similar:

You now have full access to server management and files in your home directory.

Creating a VNC Service File

First, let's create a unit file /etc/systemd/system/ using your text editor:

$ sudo nano /etc/systemd/system/

Copy and paste the following content into it. Make sure you change the User field value and the user name in the PIDFILE field to your values.

$ /etc/systemd/system/

Description=Start TightVNC server at startup
After=syslog.target network.target

Type=forking
User=sammy
PAMName=login
PIDFile=/home/sammy/.vnc/%H:%i.pid
ExecStartPre=-/usr/bin/vncserver -kill:%i > /dev/null 2>&1
ExecStart=/usr/bin/vncserver -depth 24 -geometry 1280x800:%i
ExecStop=/usr/bin/vncserver -kill:%i

WantedBy=multi-user.target

$ sudo systemctl daemon-reload

Let's activate the unit file.

$ sudo systemctl enable

Stop the current VNC server instance if it is running.

$ sudo systemctl start

Let's make sure that the service is running with this command:

$ sudo systemctl status >

If the launch was successful, the output should look similar to:

Name Conclusion
This email address is being protected from spambots. You need JavaScript enabled to view it.- TightVNC server on Ubuntu 16.04
Loaded: loaded (/etc/systemd/system/ ; enabled; vendor preset: enabled)
Active: active (running) since Mon 2016-04-25 03:21:34 EDT; 6s ago
Process: 2924 ExecStop=/usr/bin/vncserver -kill:%i (code=exited, status=0/SUCCESS) ... systemd: Starting TightVNC server on Ubuntu 16.04...
systemd: pam_unix(login:session): session opened for user finid by (uid=0)
systemd: Started TightVNC server on Ubuntu 16.04.

Ready! You were able to install and configure the VNC server on your Ubuntu 16.04 server. From now on, you can manage files, software and settings using the familiar graphical interface.

Today I will talk about installing and configuring the tightvnc vnc server in ubuntu 14.04 and 16.04. First, let's talk about why I chose tightvnc. When I first installed a vnc server, I first installed x11vnc, it was described as an easy to install and convenient vnc server. That’s right, everything works out of the box, but here’s the problem - this vnc server works with an existing user session, and does not create a new one. That is, it connects to the user's current desktop. This will suit many people, but I needed a vnc server that would create a new session upon startup. This is where the tightvnc server came to my aid. When running tightvnc, the server creates a new session for the user. The advantages of such a server are that you can set an arbitrary resolution of the created desktop, regardless of the restrictions imposed by the computer system. For example, if the remote computer allows you to set maximum resolution 1280x1024, this will not prevent you from creating a desktop with an even higher resolution using the tightvnc server. You can also create several desktops using the tightvnc server. This is very convenient when you need to organize work for several users on one computer.

So, let's start installing tightvnc server in ubuntu 16.04 and 14.04:

Sudo apt-get install tightvncserver

Running tightvnc: in the terminal we type (launch from current user, sudo is not needed)

Vncserver

When starting for the first time, you will need to enter an access password to the vnc server (minimum 6 characters), and, if desired, an access password in the “view only” mode.

The default tightvnc server port is 5901. You can specify a different port like this:

Vncserver:2

In this case, the tightvnc server will be launched on port 5902.

Running tightvnc server with a given screen resolution carried out with the geometry parameter, for example:

Vncserver -geometry 1280x1024

That is, if you type in the terminal:

Vncserver -geometry 1280x1024:3

then a vnc server with a desktop resolution of 1280x1024 pixels will be launched on port 5903. There are a bunch of other parameters - color depth and much more; this article discusses only the main ones.

Stop tightvnc server:

Vncserver -kill:1

vncserver will be stopped on port 5901.

Setting up tightvnc server

When installing tightvnc server, a startup script called xstartup is created in the /home/user/.vnc directory. The fact is that when creating a new session, tightvnc server launches regular Xs, and xstartup launches configuration file for the x-session being created, in which you need to specify all the programs that should be loaded when the x-session starts, up to and including such as a window manager, for example. That's why, if you don't edit the launch script and connect to the tightvnc server, you'll just see a gray screen. To fix this, let's edit the /home/user/.vnc/xstartup file. The first thing we need is to add a window manager there. I recommend the metacity window manager. Let's install it:

Sudo apt-get install metacity

After installation, add the line “metacity &” to the xstartup file:

#!/bin/sh xrdb $HOME/.Xresources #xsetroot -solid gray metacity &

Next you need to launch one application, at least a terminal. Depending on the distribution version linux commands to launch the terminal may vary. I have gnome-terminal installed. In your case, it may not be installed, but xterm is installed, for example. In general, look at the logs if nothing starts for you. The logs are in the same folder as xstartup.

Add a terminal line with the following line after "metacity &":

Gnome-terminal &

In principle, this is the minimum possible configuration, since you can launch any application from the terminal, but in order to fully understand the essence of xstartup, we will also add firefox browser. All together it will look something like this:

#!/bin/sh xrdb $HOME/.Xresources #xsetroot -solid gray metacity & gnome-terminal & firefox # Fix to make GNOME work export XKL_XMODMAP_DISABLE=1 /etc/X11/Xsession

After making changes to xstartup, be sure to restart the tightvnc server if it was running. Now, after connecting to the tightvnc server, the following should appear on the desktop: open terminal and firefox browser. But that is not all. If you wish, you can add many applications there, nautilus for example, well, in general, at your discretion. I would recommend adding a dock panel instead, for example gnome-panel, so that you don’t have to go into the terminal every time to launch this or that application. Let's install it:

Sudo apt-get install gnome-panel

And add it to the xstartup file instead of the terminal and firefox applications:

#!/bin/sh xrdb $HOME/.Xresources #xsetroot -solid gray metacity & gnome-panel # Fix to make GNOME work export XKL_XMODMAP_DISABLE=1 /etc/X11/Xsession

Now, when you start an x-session, the gnome panel will launch.

That's all, you can complete the tightvnc server setup. But for the hardened gnome nerds, I have something else: when you start the x-session, you can launch a gnome session. Here is the startup script for the gnome session:

#!/bin/sh gnome-session & gnome-panel & gnome-settings-daemon & metacity export XKL_XMODMAP_DISABLE=1 #/etc/X11/Xsession

I would like to warn you that I had browser glitches in my gnome session: the layout did not switch, some keys did not work correctly. In general, see what is better for you - X or gnome session.

|

VNC (Virtual Network Computing) is a remote access system that allows you to use a keyboard and mouse to interact with graphical interface desktop remote server. With its help, you can manage files, software and settings of a remote server without accessing the command line.

This guide will help you install VNC on an Ubuntu 16.04 virtual private server and set up a secure connection using an SSH tunnel. The VNC server will use TightVNC, a fast and lightweight package remote control, which supports operation even with slow Internet.

Requirements

• Configured Ubuntu 16.04 server (refer to for this).
• Non-root user with sudo access.
• A local computer with a pre-installed VNC client that supports VNC connections over an SSH tunnel. Windows users can install TightVNC, RealVNC or UltraVNC. Mac users OS X can use the built-in Screen Sharing package or use cross-platform applications (for example, RealVNC). Linux users can choose vinagre, krdc, RealVNC, TightVNC, etc.

1: Install Desktop Environment and VNC Server

By default, Ubuntu 16.04 servers come without a pre-installed graphical desktop environment and VNC server. Therefore, you first need to install these components. This tutorial uses the Xfce and TightVNC packages available in the official Ubuntu repository.

To install the specified packages on the server, enter:

sudo apt install xfce4 xfce4-goodies tightvncserver

To complete initial setup VNC server after installing it and select strong password, use the vncserver command.

The command will ask you to select and confirm a password, as well as a viewing password (optional). Users who access VNC using a browsing password will not be able to control VNC using a mouse or keyboard. This password allows you to demonstrate VNC to other users if necessary.

The vncserver command will complete the initial VNC setup and create configuration files.

2: Setting up a VNC server

First you need to define the commands that the VNC server will execute when starting. These commands should be in the xstartup file in the .vnc directory, which is stored in the current user's home directory. The startup script was created by the vncserver team, but it needs to be modified to work with Xfce.

When VNC first starts, it uses port 5901. VNC calls this port:1. VNC can run other instances on other ports, which will be called :2, :3, etc.

To change the VNC server settings, you need to stop the instance using port 5901.

vncserver -kill:1

The command will return the following message (PID will be different):

Killing Xtightvnc process ID 17648

Create a backup of the xstartup file:

mv ~/.vnc/xstartup ~/.vnc/xstartup.bak

Then create a new xstartup file:

nano ~/.vnc/xstartup

Paste into it following commands, which will be executed automatically when the VNC server starts. Save and close the file.

~/.vnc/xstartup
#!/bin/bash
xrdb $HOME/.Xresources
startxfce4&

With the first command, xrdb $HOME/.Xresources, the VNC server GUI reads the .Xresources file. In the .Xresources file, the user can make changes to some settings of the graphical desktop (customize terminal colors, cursor themes, fonts). The second command simply launches Xfce, which is where all the graphics are stored software, necessary to manage the server.

Now you need to transfer the rights to the file:

sudo chmod +x ~/.vnc/xstartup

Restart VNC:

During startup the server will return:

New "X" desktop is your_server_name.com:1
Starting applications specified in /home/8host/.vnc/xstartup
Log file is /home/8host/.vnc/liniverse.com:1.log

3: Testing the VNC Desktop

Now you need to make sure that the VNC server is configured correctly.

Create an SSH connection to local computer, redirected to the localhost of the VNC server. You can use a Linux or OS X terminal for this.

ssh -L 5901:127.0.0.1:5901 -N -f -l username server_ip_address

Note: Replace user and server_ip_address with a username with sudo access and your IP address.

If you are using a graphical SSH client (such as PuTTY), use server_ip_address as the connection IP address and then specify localhost:5901 in the SSH tunnel settings.

You can now use the VNC client to connect to the server. To do this you need to pass authentication. Enter the password set in section 1.

After this, the standard Xfce desktop will appear on the screen.

You can access your home directory files using file manager or command line.

4: Create a VNC service file

Now you need to configure the VNC server as a system service.

Create a new file /etc/systemd/system/ [email protected]:

sudo nano /etc/systemd/system/ [email protected]

Copy and paste the following code into it:

/etc/systemd/system/ [email protected]
Description=Start TightVNC server at startup
After=syslog.target network.target
Type=forking
User=8host
PAMName=login
PIDFile=/home/8host/.vnc/%H:%i.pid
ExecStartPre=-/usr/bin/vncserver -kill:%i > /dev/null 2>&1
ExecStart=/usr/bin/vncserver -depth 24 -geometry 1280x800:%i
ExecStop=/usr/bin/vncserver -kill:%i
WantedBy=multi-user.target

Note: Enter your username instead of 8host.

Save and close the file.

Restart the daemon:

sudo systemctl daemon-reload

Include the new file:

sudo systemctl enable [email protected]

Stop the current VNC server instance if it is still running:

vncserver -kill:1

Now try running it like any other systemd service:

sudo systemctl start vncserver@1

To make sure the server is running, check its status:

sudo systemctl status vncserver@1

If the server is running, the command will return:

[email protected]- TightVNC server on Ubuntu 16.04
Loaded: loaded (/etc/systemd/system/ [email protected]; enabled; vendor preset: enabled)
Active: active (running) since Mon 2016-04-25 03:21:34 EDT; 6s ago
Process: 2924 ExecStop=/usr/bin/vncserver -kill:%i (code=exited, status=0/SUCCESS)
...
systemd: Starting TightVNC server on Ubuntu 16.04...

systemd: pam_unix(login:session): session opened for user finid by (uid=0)
systemd: Started TightVNC server on Ubuntu 16.04.

Conclusion

Now on Ubuntu server A secure VNC server is installed on 16.04. It can be used to manage files, programs and settings of a remote server.

Tags: ,

How to help your users access a multi-user Linux system from anywhere

VNC and X server architecture

The graphical user interface (GUI) in Linux® uses the X Window System (abbreviated X). X is an unusual GUI in several respects, in particular it is native network interface. X server, in essence, is a network server program. Network server programs provide client programs with access to local resources, and this is true for the X server as well. The peculiarity is that in the case of the X server, “local resources” are the display, keyboard and mouse with which the user works. In the most common configuration, X client programs run on the same computer as the server. Thus, LibreOffice, the GNU Image Manipulation Program (GIMP), or other programs are X clients that use X network protocols to accept data from the user and display the results on the same computer.

However, when X is used on a network, the user sits at an X server computer, and the X clients are programs that need to be run on another computer. This configuration requires a second network protocol, establishing a connection. This second protocol could be telnet, Secure Shell (SSH), or X Display Manager Control Protocol (XDMCP). The server for this remote login protocol runs on the X client computer, and the remote login client runs on the X server computer. The remote login server runs X clients, which in turn establish a connection to the X server. illustrates this interaction. Dotted arrows indicate the beginning of the session. (With XDMCP, the XDMCP client is built into the X server program.)

Figure 1: Remote Access X requires a client and server on both computers

This configuration works great in many local networks, but is not without its shortcomings. For example, it requires a two-way network protocol to be initiated, which may be prevented by a firewall or Network Address Translation (NAT) router. (SSH removes this obstacle by allowing X sessions to be tunneled.) Additionally, although X servers exist for most platforms, they are not typically installed on computers running Windows control®. For these and other reasons, many people prefer to use another protocol, Remote Frame Buffer (RFB), which is implemented in the Virtual Network Computing (VNC) family of programs.

VNC is a cross-platform tool that provides remote access to Linux, UNIX®, Mac OS X, Windows and other systems from any type of client. The user sits at a client computer and accesses a remote server computer. In Linux, a VNC server either mirrors the contents of the local X server screen to a remote computer, or contains its own own X server, capable of running independently of whatever controls the local screen. The result is shown in Figure 2. Again, the dotted arrow indicates the start of the session. This configuration eliminates the need for reverse network connection, and since VNC clients and servers are available for many operating systems, the same client program provides access to any server.

Figure 2. The VNC server includes an X server that can communicate with local programs via X client

The disadvantage of VNC is that RFB authentication is based on passwords without usernames. So each user must start an independent VNC server session and establish a connection to that VNC instance by specifying correct number port. This requirement is tolerable for a single-user system, but causes extreme inconvenience when working on a multi-user computer.

To solve this problem, you can combine these two approaches: reconfigure the local XDMCP server so that it helps the X server built into VNC provide the missing multi-user authentication. (The resulting configuration is illustrated in Figure 3. The dotted arrow indicates the start of the session.) Now, when remote VNC users access the VNC server computer, they can enter usernames and access passwords for their own unique VNC sessions, so that the computer can be used for as long as any users.

Figure 3: Adding XDMCP to a VNC configuration provides increased flexibility

Setting up a VNC server

There are several ways to run VNC, including using scripts, binding VNC to a desktop environment using desktop tools, and using xinetd to listen for VNC connections. This latter approach is described here because it allows VNC to run in a way that can use an XDMCP server. Before moving on to the instructions for setting up VNC to run through xinetd, you must select a VNC server.

Selecting a VNC server

There are several VNC server programs. (See section). Some of the most popular are TightVNC, TigerVNC and RealVNC. This article uses TightVNC as an example. Unfortunately, configuration details are both server and distribution specific, so the instructions here will need to be tailored to your software.

Installing xinetd

Many distributions install the xinetd superserver by default, but not all. Because the method described here assumes the use of xinetd, you must install xinetd if it is not already installed. On most distributions, xinetd can be installed using a package manager, for example by calling apt-get install xinetd on Debian-based distributions or zypper install xinetd on openSUSE.

You may also need to configure the xinetd startup process. Typically, you can use the System V (SysV) startup script for a one-time startup:

# /etc/init.d/xinetd start

To configure xinetd to start automatically when the computer boots, you need to know how your distribution's startup scripts work. Typically this is done with a utility such as chkconfig (used on Fedora, openSUSE and related distributions), update-rc.d (used on Debian and related distributions) or rc-update (used on Gentoo), something like this:

# chkconfig xinetd on # update-rc.d xinetd enable # rc-update add xinetd default

Enter only one from these commands or find the equivalent for your distribution.

Note that xinetd may not start if it is not configured to run any services. So you may have to wait to run it until you have configured xinetd to manage your VNC server.

Setting up xinetd

Servers to be managed by xinetd place configuration files in the /etc/xinetd.d directory. Thus, to configure xinetd to manage VNC, you need to create or edit a file with the name type /etc/xinetd.d/vnc.(On some distributions, such as openSUSE, the VNC server package installs such a file.) Listing 1 shows an example.

Listing 1. Example of VNC configuration for xinetd

service vnc ( disable = no socket_type = stream protocol = tcp wait = no user = nobody server = /usr/bin/Xvnc server_args = -inetd -once -query localhost -geometry 1024x768 -depth 16 type = UNLISTED port = 5900 )

This entry specifies several xinetd options, most of which should be left as is. Listed below are the settings that may need to be configured.

• service. VNC with different parameters can be run on multiple ports, but in this case, in the first line of Listing 1, you need to give VNC a separate service name for each port.
• server. This parameter needs to be changed to point to the main binary file VNC server, which is usually called Xvnc.
• server_args. You will almost certainly want to change some of these values, as described below.
• port. VNC uses port numbers 5900 and above. You can run the server with different parameter values ​​through different ports. In this case, each instance must be assigned its own port number.

The trickiest part of setting up xinetd is setting the server arguments. You can use the arguments shown in Listing 1 as a model, changing some of them.

• -query localhost . This option specifies that the VNC X server should check the localhost system for XDMCP authentication. It can be changed if you want to use one computer as a translator to access the programs of another.
• -geometry 1024x768 . This option sets the virtual resolution of the VNC session. Note that this permission does not have to match the permission regular X server running on the server computer. You can create multiple entries that work with different resolutions so that users can log into the VNC server at the resolution that is convenient for them local systems.
• -depth 16 . This parameter sets the color depth. The lower the value, the faster the display refreshes, but distortion may appear on a screen with many colors. The range of valid values ​​is from 2 to 32.

There are many other options, and some of them depend on the VNC server. Refer to your VNC server documentation.

Setting up an XDMCP server

Most Linux distributions configure their XDMCP servers to only manage the local display. To enable remote access, you need to reconfigure the XDMCP server to accept access requests from a VNC server running on the same computer. The details depend on the XDMCP server. The three most commonly used on Linux are GNOME Display Manager (GDM), Light Display Manager (LightDM), and KDE Display Manager (KDM). Other XDMCP servers, such as XDM, require different settings than those described here. In any case, after reconfiguring the XDMCP server, you will have to restart it.

Editing the XDMCP Configuration File

If you are not sure which XDMCP server is being used on your system, you can determine this by viewing the process listing using the dm line, for example:

$ ps ax | grep dm 929 ? Ss 0:00 /usr/bin/kdm 962 tty7 Ss+ 0:19 /usr/bin/Xorg -br:0 vt7 -nolisten tcp -auth \ /var/lib/xdm/authdir/authfiles/A:0-pp4shb 30157 pts/3 S+ 0:00 grep --color=auto dm

The first line of this printout states that KDM is running, so in order for VNC to use XDMCP, you need to edit that server's configuration file. The configuration files of most XDMCP programs follow the same format. They contain sections with names given in square brackets, such as . The lines following the section name specify parameters using an equal sign, for example: enable=true . Table 1 lists the configuration file names, section names, and parameters that must be defined for XDMCP to work on several common Linux XDMCP servers.

Table 1. Parameters that allow XDMCP to support VNC for different XDMCP servers

The XDMCP section in the configuration file may be completely missing. If present, it may explicitly disable XMDCP support, contain commented out options, or be empty. Regardless of the initial state of the file, you must ensure that the XDMCP section is present and that support is enabled. As an example, let's look at configuring KDM to enable XDMCP:

Enable=true

Some distributions allow you to enable additional measures security that will need to be relaxed. One of them is a firewall. Firewall scripts are usually distribution-specific, so for configuration instructions firewall refer to the documentation for your system. You want localhost to have access to port 177 and VNC clients to access port 5900 (or any other ports that are used for VNC).

OpenSUSE has an additional configuration file that controls some types of access, including XDMCP access: /etc/sysconfig/displaymanager. Open this file in a text editor and find the following line:

DISPLAYMANAGER_REMOTE_ACCESS="no"

Change the value of this parameter to "yes" . If you leave "no" , the XDMCP server login window will not be displayed when connecting to a VNC server. In most distributions this change Not required: This file only uses openSUSE.

Restarting the XDMCP server

When the XDMCP server is configured to support remote connections, it needs to be restarted. On distributions that start X via a SysV init file, such as Debian and Gentoo, this can be done using the restart option:

# /etc/init.d/gdm restart

On a system that uses a runlevel to run X, such as Fedora or openSUSE, you need to go to the text mode level (usually 3) and then back to the GUI level (usually 5):

# telinit 3 # telinit 5

Keep in mind that either approach logs you out of X, so save any work you've done in your X session before continuing.

Testing and Debugging

You can now log in from a remote computer using a VNC client. Most Linux distributions include the vncviewer command, so you can type:

vncviewer

To login remotename via VNC. If VNC is configured and working correctly, the result will be something like Figure 4. If you set up multiple VNC sessions on different ports, you can specify the VNC session number by passing it as part of the hostname. Enter:

vncviewer:3

To log into session 3 (via port 5903).

Figure 4. When configured to work with XDMCP, VNC provides the usual Linux prompt

If you do not see the XDMCP login screen when you run this test, you will need to debug. Below are some recommendations.

• If vncviewer reports that the connection was refused, it most likely means that the superserver on the VNC server machine is not configured properly. Check xinetd configuration and try restarting the superserver. It is also possible that the firewall is blocking access to the VNC server computer.
• If the VNC client starts and connects to the server, but you only see a gray screen with a cursor that can be moved, the problem is most likely with the XDMCP server configuration. Check the settings above and restart the XDMCP server.
• Review the event log files as you would normally do when debugging. You may need to search for all log files in the /var/log directory using links to your xinetd, XDMCP server, and VNC server.

VNC Security Issues

RFB is not secure protocol; Most VNC clients and servers do not encrypt their data. (VNC encrypts its own passwords, but the approach described here does not use these passwords.) Be careful when choosing how and where to install VNC. If you want to use VNC in unsecured network, three options are possible:

• use virtual private network(VPN);
• tunnel protocol via SSH;
• Use a VNC option that supports encryption, such as TigerVNC with Transport Layer Security encryption capability.

When you enable VNC login windows as described in this article, external world open by at least, two ports (VNC and XDMCP). Both ports can be restricted by firewall rules to minimize the risk of abuse. Note that the XDMCP port (UDP 177) should only be open to localhost, so the firewall rule for it can be quite restrictive.

Conclusion

In general, VNC and XDMCP connection is a useful method of providing remote GUI login for multi-user Linux computers. This method has advantages over directly applying XDMCP in a cross-platform environment or when there are problems caused by a firewall or NAT. On multi-user computers, it is preferable to the more common direct VNC connection methods. There are safety issues to consider when using this method. Be prepared to configure firewall rules to restrict unwanted access externally and use encryption if data is transmitted over an untrusted network.

We present to your attention a new course from the team The Codeby- "Penetration testing of Web Applications from scratch." General theory, preparation of the working environment, passive fuzzing and fingerprinting, Active fuzzing, Vulnerabilities, Post-exploitation, Tools, Social Engeneering and much more.

Virtual Network Computing (VNC) allows for shared access other remote users to the localhost desktop environment over the network. To provide desktop access, a VNC server must be running on the local host, and remote users connect to the VNC server using some kind of VNC viewer client.

In this tutorial I will explain how to set up a VNC server on Linux. For this I will be using vino, a VNC server software for the GNOME desktop environment.

To install the vino VNC server on a machine running Debian, Ubuntu or Linux Mint:

$ sudo apt-get install vino

To install the vino VNC server on a machine running Fedora, CentOS or RHEL:

$ sudo yum install vino

After installation, you can run vino and enable the VNC server by entering the vino-preferences command.

$vino-preferences

The above command will open the vino settings window to access the desktop as shown below. In the window where “Sharing” is located, check the box to allow other users to see your desktop. You can also set a VNC password. When the settings are done, this window can be closed.

In theory, the vino-preferences utility itself should start the VNC server. If the VNC server is not running for some reason, you can start the VNC server manually as follows.

$ /usr/lib/vino/vino-server &

On the latest Linux Mint with the Cinnamon desktop, vino-preferences are known to be missing. To enable VNC server configuration in Mint on the Cinnamon desktop, use dconf-editor instead, as described here.

You can check if vino is running by typing the following command.

$ sudo netstat -pl | grep vino tcp 0 0 *:5900 *:* LISTEN 3246/vino-server tcp6 0 0 [::]:5800 [::]:* LISTEN 3246/vino-server tcp6 0 0 [::]:5900 [:: ]:* LISTEN 3246/vino-server

As you can see above, vino-server is running on TCP port with numbers 5800 and 5900. You can use any software with VNC client function to connect to the VNC server.

If the VNC server is configured so that you must confirm every VNC access to your desktop, then you will see the following pop-up message every time a VNC connection request is received. Only after you enable VNC will the VNC client be able to access your desktop.