Linux GUI remote access methods. Linux Remote Desktop

5. Move the Button bar and Location bar with the mouse.

6. Resize the panels using the dedicated resize handles on the window borders.

7. Run the vi command in the right pane.

8. On the left view pane, open the applet by pressing the keys .

9. On the bottom panel, use the compiler and other command line tools.

10. Select the Setting Save View Profile option to save the profile.

11. Enter a name for the profile and then select the Save window size in profile option. After that, to save the settings, click on the Save button.

6. Control questions

1. What programs are called file managers?

2. What information is displayed in the Konqueror viewport?

3. How do I create a new window with Konqueror?

4. List the file system management tasks that can be accomplished with the file manager?

5. List the standard KDE features.

6. What is a component of the KDE desktop?

7. Name the functions of the desktop panel.

8. How do I get online help?

9. What features does the KDE Control Center provide?

Literature 1,3,4

Laboratory work No. 9 Remote access in Linux

Purpose of work: To get acquainted in practice with the means of remote control in the Linux operating system. Gain experience and skills in remote access management

Lesson plan

4. Using theoretical information, study the purpose and rules of working with the ssh service.

5. If necessary, install the required software (ssh, sshd, putty).

6. Provide ssh access to your computer. Grant rights and a password for remote control of your computer to a neighboring - counterclockwise - computer.

7. Establish a remote connection to a remote computer. A clockwise neighboring computer acts as a Remote. That is, you must control the right computer remotely, and provide the ability to remotely control your computer to the computer on your left.

8. To make a report.

Brief theoretical information

1. Remote access protocols: telnet and ssh

The UNIX operating system was originally designed as an Internet server. Tools for working with the Network are built directly into the kernel of this operating system, and all the necessary software for organizing the server is included in the distribution kit. UNIX works better with all network protocols (especially TCP / IP) than any other operating system for the Intel platform. It’s not without reason that UNIX is said to be for the web, like a bird for flight. All of the above qualities apply to Linux as well. There are many areas where Linux servers are used: WWW servers, FTP servers, mailers, gateways. Therefore, remote control of a Linux server is of great importance.

Two protocols telnet and SSH are used for remote access to Linux. Telnet is an Internet data line protocol that enables

a computer to function as a terminal, operated by a remote computer. The telnet protocol was originally developed for ARPAnet and is an important part of the TCP / IP data transfer protocol.

There are three main problems with telnet, making it a poor choice for modern systems from a security standpoint:

The default telnet daemons have several vulnerabilities discovered over the years, and probably a few more still exist.

Telnet does not encrypt any data that is sent over the established connection (including passwords), and thus it becomes possible to eavesdrop on the connection and use the password later for malicious purposes.

The absence of an authentication system in telnet does not provide any guarantee that the connection established between two remote hosts will not be interrupted in the middle.

The use of the telnet protocol is undesirable on systems for which security is important, such as the public Internet. Telnet sessions do not support data encryption. This means it is anyone who has access to any router, switch or gateway on the network between two remote computers connected

communication session via telnet protocol, can intercept passing packets and easily get a login and password to access the system (or take over any other information exchanged between these computers) using any public utility like tcpdump and Ethereal.

SSH - (Secure Shell) is a network protocol that allows you to remotely control your computer and transfer files. It is similar in functionality to the telnet protocol, but uses encryption algorithms for transmitted information.

The shortcomings of telnet led to a very rapid phase-out of the protocol in favor of the more secure and functional SSH protocol. SSH provides all the functionality that telnet exhibited, with the addition of spectacular coding to prevent eavesdropping on data such as usernames and passwords. SSH's public key authentication system ensures that the remote computer is who it claims to be.

Since the use of the telnet protocol for remote control is incorrect from a security point of view, in this lab we will consider only remote control via SSH.

At the moment, there are two versions of the SSH protocol: Description of the SSH-1 protocol technology:

First, the client sends a request to the server to establish an SSH connection and create a new session. The connection will be accepted by the server if it accepts messages of this kind and is ready to open a new communication session. The client and server then exchange information about which protocol versions they support. The connection will continue if a match is found between the protocols and a confirmation is received that both parties are ready to continue the connection using this protocol. Immediately after that, the server sends the client the permanent public and temporary server keys. The client uses these keys to encrypt the session key. Even though the temporary key is sent in clear text, the session key is still secure. After that, the session key is encrypted with the temporary key and the public key of the server and thus only the server can decrypt it. At this point, both the client and the server have the session key and are therefore ready for a secure encrypted packet transmission session.

Server authentication is based on its ability to decrypt the session key, which is encrypted with the server's public key. Client authentication can happen in a variety of ways, including DSA, RSA, OpenPGP, or

by password. The session continues as long as both the client and server are able to authenticate each other. The established connection via the SSH-1 protocol allows you to protect the transmitted data with a strong encryption algorithm, data integrity check and compression.

Description of the SSH-2 protocol technology:

Both protocols essentially perform the same function, but SSH-2 does it more elegantly, more securely, and more flexible. The main difference between the protocols is that the SSH-2 protocol separates all the functions of the SSH protocol between three protocols, while the SSH-1 protocol is one single and indivisible protocol. By modulating the SSH protocol functions in three protocols - transport layer protocol, authentication protocol and connection protocol, SSH-2 protocol makes the most flexible and powerful mechanism for creating secure tunnels. Below is a brief description and purpose of each of the three protocols that make up the SSH-2 protocol:

Transport layer protocol - provides the ability to encrypt and compress the transmitted data, and also implements a data integrity control system.

Connection Protocol - Allows clients to establish a multi-threaded connection through the original SSH tunnel, thus reducing the load that client processes create.

Authentication Protocol - The authentication protocol is separate from the transport protocol because it is not always necessary to use an authentication system. In case authentication is needed, the process is protected by the original secure channel established through the transport layer protocol.

It should be noted that SSH does not address all network security concerns. It only focuses on ensuring the secure operation of applications such as terminal emulators. Using SSH protocol implementations on servers and in client applications helps protect data only in transit. SSH is in no way a replacement for firewalls, intrusion detection systems, network scanners, authentication systems, or other tools that help protect information systems and networks from attacks.

The SSH server is the sshd daemon that runs on a UNIX machine.

OpenSSH, PuTTY, SecureCRT, SFTPPlus, TeraTerm, etc. are currently used as an SSH client. In the laboratory practice, the most common OpenSSH will be used - for connecting a Linux client and PuTTY - for connecting a Windows client.

OpenSSH (Open Secure Shell - open secure shell) - a set of programs,

providing encryption of communication sessions over computer networks using the SSH protocol. It was created under the leadership of Theo de Raadt as an open source alternative to commercial software from SSH Communications Security.

PuTTY (from TTY - teletype, English putty - putty) is a free client for SSH protocols. It was originally developed for Windows, but later ported to Unix.

2. Setting up an ssh server on the server

To start the SSH service on the server, you need to start the sshd daemon on it. It is advisable to add a startup command to the system boot script. The sshd daemon runs on port 22. You can run it from the xinetd / inetd super daemon, but usually sshd starts on its own - in standalone mode._

The sshd server configuration file is called / etc / ssh / sshd_config. For help on its syntax, see man 5 sshd_config. The openssh-server package contains a configuration file with typical settings.

To protect your computer from unwanted intrusions from the outside, it is recommended to enter the allowedadress directive in the configuration file and list the IP addresses of those machines from which clients are allowed to enter, separated by a space. For example, for the ws2 workstation in the lab, you can allow remote connections only from the teacher's computer and the closest computer on the left:

allowedadress 192.168.1.100 192.168.1.101

Example configuration file / etc / ssh / sshd_config:

# First, we try to work using the SSH 2 protocol, and then,

# if that side does not support the second version, by SSH 1 Protocol 2.1

# Key for SSH protocol version 1 HostKey / etc / openssh / ssh_host_key

# Keys for SSH2 protocol - RSA and DSA HostKey /etc/openssh/sshjiost_.rsajtey HostKey / etc / openssh / ssh_host_dsa_key

# Lifetime and key size ssh version 1 KeyRegenerationInterval 3600

# By default, the size is 768 bits, set to 1024 ServerKeyBits 1024

# The time after which the server keys will be generated anew.

# Periodic key change increases the security of the system.

KeyRegenerationlnterval lh

# We prohibit the registration of the root user via ssh.

# This does not exclude the possibility of remote

# administration: just root will have to go under

# as a regular user, and then execute the su command.

# But the attacker will need to steal

# not one, but two passwords: both root and a regular user.

PermitRootLogin no

# Logging (uncomment if needed

# log with syslog) #SyslogFacility AUTH

# Authentication

# Includes password authentication

# and disallows empty passwords

PasswordAuthentication yes PermitEmptyPasswords no

#StrictModes yes

# use RSA authentication

RSAAuthentication yes PubkeyAuthentication yes

# Rhosts authentication - usually not used,

# therefore we prohibit it:

# custom files- /. rhosts and - /. shosts will not be used

RhostsAuthentication no IgnoreRhosts yes

# DO NOT use PAM authentication

PAMAuthenticationViaKbdlnt no

# Additional time for the client to authenticate himself.

# If during this time the client was unable to enter the password,

# connection will be terminated

LoginGraceTime 2m

# Path to banner

Banner / some / path

# Subsystem of the sftp server

Subsystem sftp / usr / libexec / openssh / sftp-server

The keys you can run sshd with are listed in table 9.1.

	Tab. 9.1. Sshd server keys.
	Appointment
	Specifies the number of bits for the server key (default 768). This option
	can only be used if you are using SSH protocol version 1
	Debug mode (DEBUG). In this mode, the server does not go to the background
	mode, handles only one connection and logs in detail
	your actions in the system log. The debug key is especially useful for
	studying the work of the server.
	Just as with the previous key, the sshd server will not
	go to the background. However, unlike -d, the -D switch does not translate

	the server is in debug mode
	Send debug messages not to the system log, but to the standard one
	error stream
	Sets an alternate config file instead of / etc / ssh / sshd_config
	Provides an unauthenticated client with an additional
	time to enter the password. A value of 0 is interpreted as infinite
	expectation
	Specifies an alternate public key file (node ​​key). Default
key_file	the file / etc / ssh / ssh_host_key is used. This key may be needed,
	to run sshd as an unprivileged user. Also
	the -h switch is often used when starting sshd from scripts that specify
	different settings depending on the time of day (during work and
	non-working hours)
	Used when you want to run sshd through the xinetd superserver. Usually
	the sshd daemon is started separately at system boot. This is due to the fact
	that the sshd daemon takes some time to generate the key
	server, before which it can respond to client requests. At startup
	through the superserver, on each connection, the superserver will be recreated
	call sshd, and that one - to re-generate the key. However, in modern
	latency is almost invisible on computers. Therefore, it is quite possible
	run sshd and through a superserver
	Specifies the time after which the server key will be recreated. By
	the default time is 1 hour. This option can only be used with
	SSH protocol version 1
	Specifies an alternate port for the sshd daemon to listen on
	instead of port 22
	"Quiet mode": do not log the session. Usually logged
	authentication start, authentication result and end time
	Test mode. Used to check the correctness of the file
	configuration
	Only IPv4 IP addresses are allowed
	Only IPv6 IP addresses are allowed
		Remote access from Linux client

Let's start the server with CentOS Linux. Use the ps (process status) command with the C (by command name) and l (long format) keys to check if the sshd daemon is running, and with the ifconfig command

check the server address (Figure 7.1).

Rice. 9.1. Checking the boot of the sshd service and the IP address of the server We can see that the sshd process is running. The parent process for him is

initialization with identifier 1. The server IP address is 192.168.100.3 as specified during installation.

Boot the client machine with Alt Linux Lite. We launch the terminal on it and check the connection with the server - we type the ping 192.168.100.3 command. As seen from Fig. 9.2 it is not possible to establish a connection to the server immediately after the download.

Rice. 9.2. Checking the connection with the Linux server

Requires IP configuration. Select (see Fig. 7.3) Settings - System Control Center - Network, enter the IP address 192.168.100.4 and click the "Apply" button.

Rice. 9.3. Configuring an IP interface on a Linux client

We again check the possibility of establishing a connection with the server. As seen from Fig. 9.4 now the client "sees" the server.

Rice. 9.4. After connecting the client to the 192.168.100 network, the connection is established Since the setting is not saved when booting from the Live-CD, set the IP address

the client needs to boot Alt Linux from the Live-CD every time. Now we are trying to connect remotely to the server.

The ssh client program can be launched with multiple keys, the format of its launch is generally the following:.

ssh [keys] [keys_with_arguments] [login_name @] host.domain [command]

We will use the l switch, which can be used to specify which user will log on to the remote machine, and the v switch, which enables the display of all debug information. We type the ssh command with the server address and these keys. As you can see from this figure, the client and the server exchanged information about which protocol versions they support (OpenSHH_4.7p1 on the client side and OpenSHH_4.3 on the server), the server sent the public RSA key and the program asks the user for confirmation to include the server in the list known hosts.

Rice. 9.5. Obtaining a public key for encrypting data from the server.

This is an important property of the SSH protocol. It is designed to protect the user against attacks known as spoofing or attacker in the middle. One of the problems associated with old protocols such as Telnet, FTP, RSH, etc., besides the fact that they transmit all information in clear text, is that these protocols are vulnerable to this kind of attack. An attacker with access to the intermediate network

can intercept your packets, store them, and then send them to the immediate recipient. Worse, it can overwrite your packages, for example by replacing ls -la mydir with rm -r mydir (delete instead of view), or send you a trailed file instead of the original via your captured FTP session. The attacker can finally just redirect your connection to another computer, so you send your password to another machine. Using this technique, an attacker will be able to find out the password that protects your account and can then log in under your name for their own purposes.

SSH provides the ability to authenticate the host you are connecting to. If you have verified the host correctly, there is no way for an intermediate device to read or manipulate your packets. Successful host verification shows that the connection is encrypted from beginning to end - your SSH client has established a secure connection directly to the SSH server, and no intermediate machines have access to this connection.

Since we are connecting to this machine for the first time, and SSH does not work like a trusted third party such as Certificate Authorities, all the key management work is yours. Your client displays a key fingerprint, an easy-to-read string of numbers that you can use to manually verify the key. If you answer "Yes, the fingerprint is correct", your SSH client will continue to authenticate, giving you the opportunity to enter your password and get started.

How do you know you received the correct key? After all, if, while connecting to the server, the attacker intercepted your SSH connection and let all the traffic through, he can slip his key to you, instead of the real public key of the host. There are several ways to authenticate a key. For example, a system owner can place a key fingerprint on their secure web page. Alternatively, you can call the host system administrator and check the key over the phone (if the possibility of a telephone conversation intercepted by an intruder is excluded).

We confirm the continuation of the connection by typing yes, and we receive a message from the program that the server is included in the list of known hosts (Fig. 9.6).

Rice. 9.6. RSA check

When you answered yes, our SSH client saved the server key in the known_hosts file, which is actually your personal Certificate Authority - a list of the keys of all the SSH servers you work with.

Now you can connect to the server remotely. We repeat the command ssh 192.168.100.3 –l root –v

and we get information about establishing a connection (Fig. 9.7), where the last stage of authentication is entering the password for the root user of the remote server computer.

Rice. 9.7. Debugging information for remote connection Enter the password for the root server user (Fig. 9.8) and enter the remote control session.

Rice. 9.8. The procedure for connecting remotely after entering the password Now you can control the server remotely. You can, for example, reboot it remotely by executing the reboot command, as shown in the following Figure 9.9.

In this figure, you can see that immediately after the reboot command, the remote connection cannot be re-established - the server has not yet booted. Once the connection is established, the ps command shows that there are two user processes running on the server - the bash shell and the ps command itself. Both processes are launched from the pts / 0 remote console.

We end the remote session with the logout command.

The developed laboratory setup allows you to study in detail the remote control of a Linux server. SSH configuration on the server can be done using the sshd_config configuration file. The user can get help on its syntax by the command man sshd_config. In the package openssh-server there is a configuration file with typical settings.

4. Remote access from Windows client

Not all operating systems have built-in SSH clients, UNIX does, Windows does not. Under Windows, you can install an SSH client - PuTTY, (the official server is http://www.chiark.greenend.org.uk/~sgtatham/putty/). Composition of the used distribution kit

PuTTY is shown in fig. 9.10.

Figure 9.10. Composition of the PuTTY distribution.

Putty is several separate programs designed to work with a unix server using the SSH1, SSH2, Telnet, Rlogin, Raw protocols. The program works on Windows for Intel x86 and Alpha, as well as UNIX. Shown in fig. 9.11 the complete set of programs, under the general name PuTTY, consists of the following utilities:

- putty.hlp - help file;

- putty.exe - a client for connecting to a server using telnet, ssh, raw, rlogin protocols;

- puttygen.exe - rsa / dsa key generator;

- pageant.exe is an authentication agent that stores keys in memory; when using it, you do not need to manually enter a key passphrase;

- plink.exe - command line interface for putty;

- pscp.exe - safe file copying;

- psftp.exe is a secure ftp client for copying, viewing, renaming files, etc.

Installing putty is optional, you can just copy the files to the desired directory.

Run putty.exe and create a profile with settings for our remote server. In PuTTY, you can create profiles for various SSH servers, so you don't have to drive in settings for a specific server when you want to connect to it again. We are now in the Sessions category (see the tree on the left in Figure 9.11). Enter the host address 192.168.100.3 in the Host Name (or IP adress) line, leave the default port number (22) and Protocol (SSH). Under the Saved Sessions label, enter the profile name, for example, Session with CentOS, which will help you remember which server this profile belongs to.

Figure 9.11. Creating a profile with settings in PuTTY

Then go to the Connection -> Data category and specify in Auto-login username (see Fig. 9.12) the username under which we will connect to the SSH server - root.

Figure 9.12. Set the username of the remote host

Now back to the category Sessions, save the profile by clicking Save. The next time you start PuTTY, simply select the appropriate profile from

Saved Sessions, click Load and Open.

We can now connect to our SSH server by simply clicking Open. When this client connects for the first time, a warning appears (see Fig. 9.13).

a security risk similar to the message shown in Fig. 9.5. This is because PuTTY does not yet know the public key of the server host. PuTTY writes the host key for each server you join to the Windows registry. Every time you connect to the server, it verifies that the host key provided by the server is the same key as the last connection. If this is not the case, you will receive a warning and will be able to terminate your connection before you type in any private information (such as a password). Since we are connecting to the server using the SSH protocol, everything said in the previous above regarding checking the server's public key for connecting a Linux client applies to this connection.

In our case, there are no doubts about the authenticity of the server - we press the button

Rice. 9.13. PuTTY warning when first connecting to remote host

Since we have saved the name under which we are connecting in the profile settings, we do not need to type it in again, we will only specify the user's password (Fig. 9.14).

Rice. 9.14. Remote Server Control Session

The remote connection has been established. In fig. Figure 9.14 shows a few commands running on a remote Linux server and then rebooting the server remotely. After a reboot, the session becomes inactive. It should be closed and reconnected to the server when it boots up.

The most common method of connection was considered - with password identification. If someone knows the name and password, they can connect too. Therefore, if you have a simple password and / or are the victim of a brute-force attack, there can be problems. Alternatively, you can use the method User authentication using public key encryption. You can use PuTTYgen to generate a private / public key pair. Then the public key will need to be transferred to the server, and the private key will be attached to the PuTTY profile. These procedures are detailed in the putty.hlp manual.

Thus, the developed laboratory setup allows you to study in detail the remote control of a Linux server from a Winows client.

Work order:

1) Check if it is running super server xinetd. If not running, install super-

server from xinetd-2.3.14-10.el5.i386.rpm package. (/ usr / sbin)

2) Check using find command for presence and location ssh server shhd. If sshd is not installed - install from packages

openssh-4.3p2-16.el5.i386.rpm, openssh-askpass-4.3p2-16.el5.i386.rpm; openssh-server-4.3p2-16.el5.i386.rpm. (usr / sbin)

Date of publication: Tuesday, January 19, 2009 10:43:53
Translation: Kovalenko A.M.
Date of transfer: August 4, 2009

Are you using both Windows and Linux? Can you remotely control Windows from Linux (Ubuntu or another distribution) or Linux from Windows? Surely you can. Similar to how used Remote Desktop Connection between Microsoft platforms (or remote control between Linux machines), it is possible to control the desktop from different platforms. You can click on the desktop and launch applications, just as if you were sitting right in front of your computer.

We will discuss a few different possibilities that you can get using Remote Desktop Connection. Plus, we'll walk you through the method of setting up a remote desktop connection step by step using free tools. So let's get started.

Choosing a Remote Desktop Protocol

Remote desktop applications typically use either Remote Desktop Protocol(RDP) or protocol Virtual Computing Network(VNC). To establish a remote connection, both nodes (server and client) must support the same protocol. The problem is that not all operating systems (OS) use the same default protocols. In addition to this, some Linux distributions and some editions of Windows do not include a remote desktop server or client application, or do not contain a remote desktop application at all.

Your first task should be to identify a protocol that is already supported on your computers. In addition to researching your OS, looking for documentation, links to cheat sheets, you should be able to understand what is what and where. Then, at the end, you must choose a protocol to use on all of your computers.

Note:

• Remote Desktop VNC is usually slower than RDP connections; however, VNC is usually easier to implement on different platforms.
• For better performance and security, you can use the free NoMachine's NX server and clients, or the FreeNX server and clients, but it is more complicated to set up and takes some thought.
• It is also possible to provide support for RDP connections on Linux machines, for example using an xrdp server.

Opening a firewall (firewall)

Before proceeding to establish or accept remote connections, you need to configure your firewall software. The computers you want to connect to remotely must allow VNC or RDP traffic through the firewall.

On Windows, when you start the server, you should receive a request to Block or Allow access to the network for the Remote Desktop Server application. If you click the "Allow" button, everything should work. If you do not receive a request, you can go to the properties of Windows Firewall and add permission for this application manually using the port numbers indicated below.

On Linux, you will most likely need to manually add inbound rules in the firewall on the host that accepts connection requests. If necessary, you can bring up a browser from the menu and search Google for information on how to configure the firewall. Your Linux distribution may include a GUI (Graphical User Interface) for your firewall, or you can use the command line to configure it. In the same way, add an exception or rule to allow traffic on the appropriate ports listed below.

• RDP uses TCP port 3389
• VNC uses ports starting at 5900 (each remote connection to the server uses a different port; display 1 uses port 5901, display 2 uses port 5902, and so on). The best method, therefore, is to scopes ports (such as 5900 - 5905) when you create a firewall rule or exceptions.

Now you have the ability to remotely connect to computers on your local network. To connect remotely over the Internet, you must also configure your router. We will discuss this in the next part.

Using VNC Server and Client on Ubuntu

If you are using Ububntu, you already have a VNC client and server installed and ready to use. (This article is based on the Ubuntu Desktop 8.10 Intrepid Ibex distribution.) To be able to accept remote connections, simply select from the menu System> Properties> Remote Desktop... In the dialog box, configure the desired shares and security settings. The command / address list is presented to you to specify other computers on the local network with Ubuntu or other Linux distributions installed from which to connect.

To use the VNC viewer (viewer) on Ubuntu, select Applications> System Tools> Terminal... If you are connecting to a computer with Ubuntu installed, type the command provided by Ubuntu. If you are connecting to a computer on which another Linux distribution is installed, the following command format is used:

$ vncviewer Computer_Name or _IP_address: #

as shown in Figure 1. This line contains the command, vncviewer, followed by the name or IP address of the computer (or Internet IP if connecting via the web), ending with a colon and the ID of the display (tunnel). If you are connecting to a computer on which Windows is installed, then the colon and display number are not indicated, in this case the command format is as follows:

$ vncviewer ComputerName_or_IP_address

picture 1

Installing VNC Client and Server on other Linux distributions

If you are using a Linux distribution other than Ubuntu, search their repositories for the appropriate packages to install the VNC server and client. If there are no such packages, then you can download TightVNC directly from their website and follow the assembly and installation instructions.

The TightVNC / RealVNC server has no GUI, you have to use the command line, but don't worry - it's easy. Just open Terminal, type vncserver and press Enter. On first launch, you will be prompted to create a password for VNC connections. After you set the password, the display or tunnel will be automatically configured as shown in Figure 2.

picture 2

VNC supports multiple displays to provide access to a large number of users and / or to define options for attributes such as screen resolution, startup commands, etc. Each time it runs, the vncserver command creates a new tunnel, usually numbered 1, which is incremented by one each time the command is run.

The following are the various options for the vncserver command that are useful to remember:

• For help, use the -help option or enter the man vncserver command.
• Using the -name desiredname option you can assign a name to a specific tunnel or display that appears in the VNC client's title bar when remotely connecting to that display.
• Correction: # allows you to manually define the tunnel or display number.
• Using the -geometry WxH option you can set the screen width and height for the remote desktop display.
• By adding -depth # you can set the color depth from 8 to 32 bits per pixel.
• To close the VNC tunnel, use the -kill: # option, replacing the hash icon with the desired tunnel (display) identifier.

Depending on the specific Linux distribution and VNC solution that is installed, you may or may not have a graphical user interface for the client or viewer application. If there is a graphical interface, feel free to use it, but if you want, you can use the command line as well.

For a graphical interface, you can usually configure options from a dialog box. When connecting to a Linux machine, type the computer name or IP address of the remote machine (or Internet IP when connecting over the web), followed by a colon, tunnel or display ID and press Enter. For example ericlinuxbox: 1 or 192.168.0.122:1. If you are connecting to a Windows machine, the colon and display number are not required. To connect from a terminal, enter vncviewer and host information in the same way as shown in Figure 1 earlier.

Installing VNC Client / Server on Windows

TightVNC also offers a client and server in a Windows version on its download page. After installing TightVNC, you can start the server from the menu Start (approx. translator: Start> All Programs> TightVNC) by selecting Start TightVNC Server. This will bring up a properties dialog box (see Figure 3), where you must assign a password for incoming sessions.

picture 3

After checking all the settings, click OK. The server will be started and ready to receive incoming connections, while the server icon will appear in the system tray. Again, don't use a colon and display number when connecting to a Windows computer from any platform.

If you are connecting to a remote computer from Windows, select the TightVNC Viewer shortcut from the start menu. Likewise, to connect from other platforms, enter the name or IP address of the remote computer (or Internet IP address when connecting via the web), and when connecting to a Linux computer include a colon and display number in the command.

It can be seen as an act of aggression, but sometimes it is simply necessary.

There are cases when users use remote sessions for an already used machine (sounds unusual, but it takes place for organizing work with multiple desktops). Most users do not know when exactly they will need this functionality.

Experienced Unix users often talk about SSH and the command line as tools for gaining access to a graphical desktop, but there are separate applications for this purpose.

Techradar has tested the VNC system and its features in many clients. However, there are other protocols and types of remote desktop access. The growing popularity of such clients lies in the support of several transmission protocols, so regardless of the type of server used and the target machine, you will find a suitable solution.

The researchers adhered to the principle of fair evaluation of the various protocols. For example, NoMachine NX supports VNC connections, but it was tested in conjunction with its own NX server, which makes sense.

The TightVNC client has not been tested because it is very similar to the TigerVNC implementation. Both products have the same codebase, but TigerVNC has a few additional features.

How was the testing done

A key element of an effective remote desktop client is quick response to operations. An ideal interface won't be as good if you have to wait two minutes for each keystroke registration.

The tests tested the ability to remotely play the game Armegatron. In this undemanding OpenGL game, it takes a split second to refresh the screen. The results can be somewhat subjective, but this method has proven to be very effective in demonstrating customer responsiveness.

Clients were tested in conjunction with a local computer with a 4-core processor and 16 gigabytes of memory on a gigabit LAN running Ubuntu 14.04.3. The servers used were the X11 VNC server and the official NX server for NX clients. RDP-based functionality is supported by some products but has not been tested in practice.

The clients themselves worked in a virtual machine with a 2-core Core i7 process, 4GB of RAM and Fedora 23.

The RUVDS technical support service is regularly contacted about the GUI and remote access to it on virtual servers running Linux, despite the fact that there are a lot of materials on the Internet covering this problem. Therefore, for our users, we decided to collect everything on this topic in one article.

You can also forward RDP traffic through an SSH tunnel. To do this, you need to correct the xrdp configuration file:

$ vi /etc/xrdp/xrdp.ini
Add the line to the section: address = 127.0.0.1

$ systemctl restart xrdp
You can check that everything is correct as follows:

$ nmap -p 3389 Starting Nmap 6.47 (http://nmap.org) at 2016-10-04 13:07 MSK Nmap scan report for unspecified.mtw.ru () Host is up (0.0087s latency). PORT STATE SERVICE 3389 / tcp closed ms-wbt-server
Then if you are using cygwin or mingw, linux or mac os:

Ssh [email protected]-L 3389: localhost: 3389
If PuTTY:

Start PuTTY. In the tree menu on the left, Connection → SSH → Tunnels. Next, add a new Forwarded Port (Source port: 3389, Destination: localhost: 3389). Click Add.

VNC

Customer:

For example, let's put this DE:

$ apt-key adv --recv-keys --keyserver keys.gnupg.net E1F958385BFE2B6E $ echo "deb http://packages.x2go.org/debian jessie main"> /etc/apt/sources.list.d/x2go .list $ echo "deb-src http://packages.x2go.org/debian jessie main" >> /etc/apt/sources.list.d/x2go.list $ apt-get update $ apt-get install x2go- keyring && apt-get update $ apt-get install x2goserver x2goserver-xsession
The output of the following command should show that x2go is ready to go:

$ systemctl status x2goserver ● x2goserver.service - LSB: Start and stop the X2Go daemon Loaded: loaded (/etc/init.d/x2goserver) Active: active (running) since Tue 2016-10-11 22:05:51 MSK; 30min ago ...
And now an important point, you won't be able to connect without this fix! You need to find the line "mesg n" in the .profile file and replace it with "tty -s && mesg n".

$ vi .profile
The following command will print the path to the startfluxbox executable file, which will be needed when configuring the client:

$ whereis startfluxbox
Server installation on Ubuntu:

$ apt-get install xfce4 xfce4-terminal $ add-apt-repository ppa: x2go / stable $ apt-get update $ apt-get install x2goserver x2goserver-xsession

$ vi .profile
Server installation on CentOS:

$ yum install epel-release $ yum install x2goserver x2goserver-xsession
The Linux client is installed from the above repositories with the following command:

$ apt-get install x2goclient
For Windows - download, install, run. The same link above has a client for OS X.

Launch the client:

In the session settings, we specify: in the Host field - the IP of your server, in the Login field - root, leave the port as it is, session type - the GUI that you installed.

As you can see, there is a key authentication option. In general, a lot of things. See for yourself. And the sound can be output through PulseAudio.

After clicking Ok, you will see such charming things that you need to click to receive a request to enter a password and connect to the selected session:

Note: please note that your favorite FluxBox is not in the list, so you have to write the path to it manually.

An important feature of x2go is the ability to run any graphical application without installing DE at all. To do this, in the session settings, you need to select the single application item in the session type section and select the application to be executed or enter the path to the program to be launched.

In this case, the software installation on the server will look like this. In the case of Ubuntu:

$ add-apt-repository ppa: x2go / stable $ apt-get update $ apt-get install x2goserver x2goserver-xsession
And now an important point, you won't be able to connect without this fix! You need to find in the file .profile the line "mesg n || true "and replace it with" tty -s && mesg n ".

$ vi .profile $ apt-get install firefox xterm
And by setting up the session as shown below, you can launch the browser on the remote server, and a window displaying it will open on your machine:

Or so; then a terminal window will just open:

Below you can see a screenshot of the current session status window. Buttons are marked with orange numbers:

1. "Suspend session" - after clicking on this button, the connection will be terminated, but the session will remain and will wait for the reconnection. All applications launched by you on the server will continue to work;
2. "Terminate session" - after clicking, the connection to the server will be terminated, and the applications you started on the server will be terminated.

TeamViewer

The last way to access your desktop remotely.

Installation on Ubuntu:

$ apt-get update $ apt-get install lubuntu-desktop $ reboot $ dpkg --add-architecture i386 $ apt-get update $ wget http://download.teamviewer.com/download/teamviewer_i386.deb $ dpkg -i teamviewer_i386 .deb $ apt-get -f install $ teamviewer --passwd
Installation on Debian:

$ apt-get update $ apt-get install lxde lightdm $ reboot $ dpkg --add-architecture i386 $ apt-get update $ wget http://download.teamviewer.com/download/teamviewer_i386.deb $ dpkg -i teamviewer_i386. deb $ apt-get -f install $ teamviewer --passwd
Installation on CentOS:

$ yum groupinstall "X Window system" $ yum install epel-release $ yum install fluxbox xterm lightdm $ systemctl set-default graphical.target $ reboot $ curl -o TeamViewer_Linux_PubKey.asc -Lk http://www.teamviewer.com/link /? url = 354858 $ rpm --import TeamViewer_Linux_PubKey.asc $ curl -LOk http://download.teamviewer.com/download/teamviewer.i686.rpm $ yum install teamviewer.i686.rpm $ teamviewer --passwd
You also need to accept the TeamViewer license agreement, this can be done using Emergency Mode, or add the following lines to the end of the /opt/teamviewer/config/global.conf file:

$ echo "EulaAccepted = 1" >> /opt/teamviewer/config/global.conf $ echo "EulaAcceptedRevision = 6" >> /opt/teamviewer/config/global.conf $ teamviewer --daemon restart
The following command will show the status of the TeamViewer daemon and the nine-digit TeamViewer ID required to connect:

$ teamviewer --info

After starting the client downloaded here, you need to enter the TeamViewer ID in the Partner UD field and click on the "Connect to partner" button. Next, TeamViewer will ask for a password:.

Instead of a conclusion

That seems to be all. We hope that this article will help linux server users in setting up a comfortable and convenient environment for them.

Remote Desktop allows you to connect to your computer over the Internet using another computer or even a smartphone. You may often need to do something on another computer, even if you are not near it. Ubuntu also has this capability.

In this article, we will take a look at how to set up Ubuntu 16.04 Remote Desktop, as well as how to connect to it using various devices. We will use VNC as the remote access protocol, it is slow and already outdated, but it is supported everywhere. In Ubuntu 16.04, almost all software is already installed by default, you just need to change a few settings.

Ubuntu Remote Desktop

As I said, we will use VNC as the remote access protocol. And as a server - Vino, this program is supplied by default along with the distribution. And you just have to make a few settings for it to work.

Open the main Dash menu and type in search Desktop Sharing.

If the system doesn't find anything, this is a common bug. You can run the utility through the terminal. To do this, open a terminal with Ctrl + Alt + T and run:

vino-preferences

Next, in the window that opens, check the box "Let other users see your desktop" Then opposite the field "Require password" enter the password that will be used to connect:

Everything here, ubuntu remote desktop is set up. And now you can try to connect to your computer using another Linux distribution. But there is one more thing. You will not be able to connect from Windows. Mandatory encryption is enabled by default. And this is not supported by all clients. To disable forced encryption, you need to install dconf-editor:

sudo apt install dconf-editor

Then open the program and follow the path org.gnome.desktop.remote-desktop there, uncheck the box:

You are now ready to test your ubuntu remote desktop connection. Open the main menu and find the Remmina remote connection client.

In the connection string, select the protocol VNC, then enter the address, since we are going to check on the local machine, then enter localhost, otherwise you will have to use the ip address of the computer. Next click "Connect":

Immediately, the program will ask you for a password to gain remote access to the computer:

And then, already in the VNC system, the server will ask whether it is necessary to allow connection to the ubuntu 16.04 remote desktop to this client:

After you approve the connection, you can use Remote Desktop. Now is the time to connect from another computer. You can use any VNC client for Linux, Windows or Android and connect to your computer if it is on the local network. In addition, you can access it even over the Internet by creating a private local area network, for example using hamachi or OpenVPN.

conclusions

In this article, we looked at how to set up Ubuntu 16.04 Remote Desktop and how to access it using other devices. Everything is very simple, even simpler than with the same x11vnc, for which you need to create several configuration files. If you have any questions, ask in the comments!

Related entries: