As a Linux system administrator, you are responsible for many machines that may be located locally or on distant sites.

In some cases, you will need to connect to them in order to fix an issue with disk space for example.

If you are working with users, some of them may get stuck in an application and you will have to kill the application for them.

In order to perform all those operations, you will need to remotely access those instances from your own computer.

Working with remote Linux instances can be done with handful different solutions depending on your needs.

Sometimes, you simply need to have a remote shell bound to a remote host.

However, what if you are working with an application that requires a graphical interface?

In this tutorial, we are going to explore all the ways of working with remote Linux systems.

From X11, to SSH until XRDP, you will learn everything that there is to know about remote Linux system administration.

Remote communication basics

Before listing and detailing the different ways of connecting to remote Linux hosts, you have to understand a few basics related to the way computers communicate.

Client-server model

Nowadays, computers are rarely standalone computers, they actually communicate with other computers all the time.

When you are browsing the Internet in order to retrieve a web page, you are communicating with another computer in order to perform this task.

When you are playing your favourite game, you are also communicating with another computer (or many different computers) in order to know if you won or not.

All those tasks are based on the same model : the client-server model.

The client-server model is one model that defines and organizes how communication takes place between two computers.

In this scenario, one computer is acting as the client (the one that asks for resources or computation) and another computer is acting as the server (the one that does the work, that performs the computation).

client-server

As you probably understand it, the server is responsible for the actual work and clients are only responsible for delivering the end information to you.

Note : is it the only way for computers to communicate? Not at all, peer-to-peer is another way for example. Ever tried sharing files online via tools like Bittorrent?

Client-server model examples

Now that you know a bit more about the client-server architecture, it is time to unveil what protocols are based on this model to exchange information.

The most famous protocol based on the client-server architecture is the HTTP protocol.

As a reminder, the HTTP protocol is used in order to fetch HTTP resources (usually web pages) from a HTTP server.

In this scenario, you are contacting a remote HTTP server and you are asking for a specific page.

If you are allowed to communicate with this server, you will be answered with the resources that you asked for : usually a web page.

Client-server model examples http-protocol

Note : HTTP servers can be used in order to deliver web pages, but they can be used to download files remotely, or access any kind of information located on a HTTP server

Great!

But why were we talking about the client-server model in the first place?

Because most of the ways of working remotely with Linux systems are based on the client-server model.

Secure and unsecure protocols

In our case, we are not interested in requesting web pages from a distant server.

We are interested in being able to execute commands remotely from one machine (the client) to another (the server).

In order to execute commands remotely from one computer to another, you can choose between two protocols : telnet and SSH.

Telnet protocol

Developed in 1969, telnet is a protocol enabling a bi-directional communication between two hosts in order to be able to send commands remotely.
telnet-2

The telnet protocol is based on the client-server architecture we saw before : a client connects to a TCP server (usually located on port 23 of the remote machine) and starts writing down commands to be executed.

The TCP server understands those commands, performs those operations on the server and returns the output of the command.

If you install a telnet server on your machine, you would be able to connect to it and run commands remotely.

$ sudo apt-get install telnetd -y

$ sudo systemctl status inetd

telnetd

From there, you can use a simple Telnet client in order to connect to your remote server.

$ telnet 127.0.0.1 23

telnet-example
In this scenario, my TCP client is connecting to my remote host and sending commands through the network.
telnet

Awesome, so what’s the catch?

The Telnet protocol is not encrypted.

In short, it means that if a spy was to spy on the network traffic, it would be able to see all the commands that you are sending, as well as the results of your commands.

This is a big issue because most of the time you are accessing distant servers that are located outside your premises, on distant sites where you might not be in complete control of the security.

If you were for example to connect to a SQL database, your username as well as your password would be sent over the network in plain text.

Luckily for you, there is another protocol, safer than Telnet, that was developed in order to execute commands remotely : the SSH protocol.

SSH protocol

On the other hand, the SSH protocol is completely secured.

ssh-1

SSH stands for Secure Shell and it is widely used in order to perform commands remotely in a safe and secure way.

In short, SSH is built on common cryptographic techniques: symmetrical encryption or asymmetrical encryption for the most part.

Those two techniques are in a way verifying the identity of the two hosts as well as encrypting the traffic between those two hosts.

The SSH protocol is also based on the client-server model we saw earlier.

When connecting through SSH to distant servers, you are essentially talking with a SSH server, located remotely, with a SSH client located on your machine.

Note : as you can see in the diagram, the port number should be customized in order to avoid having SSH brute force attacks on your SSH server.

ssh-protocol

In this case, as the traffic is encrypted, if somebody spies on the traffic it won’t be able to read the content sent.

In this tutorial on remote Linux system administration, we are going to focus on the SSH protocol as the Telnet one is considered obsolete in terms of security.

Execute shell commands remotely using SSH

In order to execute commands remotely, we are going to install a SSH server on our host.

There are plenty of different SSH servers but we are going to use an open-source alternative called OpenSSH.

OpenSSH was first released in 1999 and it provides a suite of secure networking tools in order to ensure communications between different hosts over SSH.

OpenSSH brings a SSH server but it also brings many different utilities that are using the power of SSH such as sftp, scp or ssh-keygen.

OpenSSH Server Installation

First of all, you need to install the OpenSSH SSH server on your host.

By default, OpenSSH may be installed depending on your distribution, but you will have to make sure that this is the case.

First, for safety purposes, make sure to update the packages on your system.

$ sudo apt-get update

To install OpenSSH, run one of those commands depending on your distribution (APT or YUM)

$ sudo apt-get install openssh-server

$ sudo yum install openssh-server openssh-clients

Running those commands, the OpenSSH server will be installed on your computer.

$ sudo systemctl status sshd

sshd-service

By default, the SSH server is listening to connections on port 22 as described in the previous sections.

In order to verify that this is the case, run the “netstat” command to list open ports.

$ sudo netstat -tulpn | grep 22

netstat-1

Great!

Your SSH server is now listening on incoming connections from port 22.

Updating firewall rules

As you probably know, the Linux operating system manipulates a built-in firewall that will blocks unauthorized requests.

This built-in firewall can be manipulated with the iptables utility which is one of the tools of the Netfilter framework.

In our case, on Debian recent systems, we are manipulating the UFW front-end in order to manipulate rules.

On CentOS or RHEL systems, you will have to update the FirewallD rules.

To allow SSH traffic on your host, run of the following commands.

$ sudo ufw allow ssh         (on Debian/Ubuntu systems)

$ sudo firewall-cmd --permanent --zone=public --add-service=ssh    (on RHEL/CentOS systems)
$ sudo firewall-cmd --reload

Next, make sure that your settings were correctly taken into account

$ sudo iptables -L | grep ssh

iptables-greop

Connecting to your SSH server

Now that your SSH server is up and running and that traffic is allowed on port 22, it is time for your client to connect.

On your client machine, make sure that you have the SSH utility.

$ ssh -V

ssh-client-version

If you are getting the following output, it means that the SSH client utility is currently installed on your machine.

In order to connect to your SSH server, simply use “ssh” followed by your username and the IP address (or hostname if it is configured) of your SSH server.

$ ssh <username>@<ip|host>

ssh-remote

Right off the bat, you are asked to verify the identity of the SSH server you are communicating with.

Known hosts

When first connecting to your remote SSH server, you are asked to verify the authenticity of the host.

The SSH utility displays a ECDSA key-fingerprint that can be used in order to verify the server authenticity.

Unless you want to verify the identify of your SSH server, you want to enter “yes”.

As a consequence, the server identify will be added to your known_hosts file located in the .ssh directory.

$ cat ~/.ssh/known_hosts

Executing commands

Now that you are connecting to your SSH server, you can start executing remote tasks on your server.

$ ls

ls-command-remote

Your commands are not executed on your local machine but they are executed on the remote machine.

To verify it, run a command that is simply sleeping for an extended period of time on the client.

$ sleep 100

Back on the server, you can actually verify that the command is actually running on the server.

server-ssh

You can even see which user started it and the terminal it used in order to start it.

Great!

But what if you wanted to execute a graphical application, like Firefox for example?

$ firefox

firefox-no-display

When trying to execute a graphical application remotely, you will get an error message stating that you have no DISPLAY environment variable specified.

So what happened here?

In order to execute graphical applications remotely over SSH, we are going to dig deeper into another protocol that is used to draw applications remotely : the X11 protocol.

Execute graphical applications remotely using X11 forwarding

Before executing your first commands with X11, you will have to understand how applications are being displayed on Linux hosts.

Understanding the X protocol

Back in the early days on Linux, users did not have any graphical applications or desktop environments installed on their computers.

Instead, they were dealing with plain terminals in order to execute commands (also called tty terminals)

Later on, graphical applications, relying on window systems, became popular and were used as a way to democratize administration for users.

In order to be able to display windows on the screen, the X protocol was invented.

The X protocol, also known as the X Window System Core Protocol, is a client-server protocol where applications (known as X clients) are connecting to X servers.

X servers, also known as display servers, are responsible for transmetting data from the user to the client applications, receiving the response from client applications and communicating with drivers in order to render your application.

In short, a X server is responsible for making applications appear on your screen.

x-architecture

As a consequence, every Linux system that is running graphical applications has a display server running on them.

This is an important concept to grasp because it essentially means that the graphical interface is decorrelated from the process itself.

As a consequence, programs can be run on distant machines but they can be presented on other machines : your local machine for example!

In this case, this is the architecture that you would have.

remote

In this example, you have two separate computers, but each computer has a display server running on it.

This is also an important point to grasp because even if the X protocol is based on the client-server model, the client AND the server might be located on the same computer.

Now that you know more about the X protocol, let’s see how applications are being displayed on your physical computer screen.

X Protocol & Displays

As detailed before, the display server (also called X server) located on your computer will be responsible for drawing graphical interfaces on your screen.

As a consequence, display servers need to be connected to display devices that are most of the time materialized as computer screens.

In order to know where the graphical interface needs to be drawn, your session has a DISPLAY environment variable that details the output device.

$ echo $DISPLAY

echo-display

The syntax for the DISPLAY environment variable is as follows :

hostname:D.S

Where :

  • hostname : the name of the computer where the display server runs. In this case, this is omitted meaning that it runs on localhost;
  • D : represents the number of displays connected to your computer. If you have two screens, you might get a different sequence number;
  • S : represents the screen number in case your display device has multiple screens.

In this case, we are in the standard case, meaning that the display server displays graphical interfaces on the localhost machine, on the first screen.

The xrandr command can be used in order to see screens connected to a Linux system.

$ xrandr --query

querying-displays

When running X clients applications on your instance, graphical instructions will be redirected to your main screen, but what if you wanted to have applications running on your server and the graphical interface on your local machine?

For this, we are going to use SSH forwarding.

Using SSH and X11 forwarding

When using the SSH client, you can append the “-x” option in order to redirect X11 traffic to your local machine.

As a consequence, the application will run on the server but it will be displayed on your client.

$ ssh -x <user>@<host>

remote-ssh-x

As you can see, when displaying the DISPLAY environment variable, the output is quite different.

This time, we have the hostname (localhost), the device number (10) as well as the screen number (0).

In this case, the device number is not actually connected to a real piece of hardware on the server but it is mapped to a remote connection on the server.

To illustrate that, try listing the open connections on your server starting with 60.

open-ports

As you can see, there is one line stating that one application is listening on port 6010 : this is actually the end point used in order to access remote displays on the server.

With that in mind, you are now able to forward the X11 traffic to your client, meaning that you can launch graphical applications from the server to your client.

On the client, while being connected to a SSH session, try running Firefox.

$ firefox

firefox-display

Awesome!

You are now able to run graphical programs remotely.

The Firefox process is running on the server, but the graphical interface is displayed on the client.

Now displaying graphical applications is fantastic, but what if you wanted to display whole desktop environments?

For this, you need to deal with what we call the RDP protocol.

Execute remote desktop using the RDP protocol

Developed by Microsoft and embedded in the early versions of Microsoft Windows servers, the RDP protocol is a proprietary protocol used in order to provide remote desktop access.

The RDP is well established on Windows operating systems and you might have already dealt with the RDP client on your Windows machine : mstsc.

xrdp-windows

Luckily for you, Linux has a wide variety of open-source alternatives in order to be able to access your Linux system remotely.

The RDP protocol is also based on the client-server model : on one hand you will have a RDP server sitting and waiting for connections on port 3389.

A popular implementation of the RDP protocol on Linux is the xRDP project that is essentially an open-source RDP server.

On the other hand, you will have a RDP client making connections to this remote server and forwarding the display to your RDP client program.

Popular RDP clients on Linux can be RemminaTigerVNC or RealVNC.

You can even use the mstsc Windows client if you are on a Windows machine.

Here is an example of a RDP connection to a Linux host using a Microsoft host computer.

Conclusion

In this tutorial, you learnt a bit more about the different ways of working with Linux systems remotely.

You learnt about at least four different ways of doing so : using the Telnet protocol (which is not used anymore today), the SSH protocol (which is far more secure), the X protocol (used in order to display graphical applications remotely) and the RDP protocol (in order to display remote desktop environments).

If there are tools that you use and that you want to share with the community, make sure to leave a comment below with your implementation, it always helps.

Also, if you are curious about Linux system administration, make sure to have a read at our other tutorials on the subject.

Leave a Reply

Your email address will not be published.