Linux Networking Introduction

Shadow Passwords

You may have noticed that instead of an encrypted password in your /etc/passwd file you have something like:

t0rrant:x:1001:1001:Manuel Torrinha,,,:/home/t0rrant:/bin/bash

The /etc/passwd file, which contains information about all users, including their encrypted password, is readable by all users, making it possible for any user to get the encrypted password of everyone on the system. Though the passwords are encrypted, password−cracking programs are widely available. To combat this growing security threat, shadow passwords were developed [8]

When shadow passwords are enabled the password field in the /etc/passwd file is replaced by an "x" and the user's actual password (encrypted) is stored in the /etc/shadow file. This file is only readable by the root user which makes it a safer place to keep such sensitive information.

File Types

In Windows systems you are probably used to distinguishing a file's type by its extension. If you have a file named myfile.pdf it represents a Portable Document Format (PDF) file, and Windows "knows" which application should open such a file because it has stored somewhere the relationship between file names ending in .pdf and the Adobe Reader application.

The same is not true for Linux systems. In fact, besides the file extension, the file itself has information of what type it is in the first bytes of the file. If we could take a look at the start of the PDF file as it were a normal text file we would see something like this:

  %PDF-1.4

Let us take a look at another file type, Portable Network Graphics (PNG) for example

  �PNG

That � character appears because the content cannot be converted to another readable character, which means that there is something there, just not in a usual readable format.

So we can see that files themselves have information of which type of file they are.

Simple Commands

Here we will see some commands we can enter in Bash that interact with different Linux components.

t0rrant@testing:~$ whoami
t0rrant
t0rrant@testing:~$

t0rrant@testing:~$ groups
t0rrant sudo
t0rrant@testing:~$

t0rrant@testing:~$ id
uid=1001(t0rrant) gid=1001(t0rrant) groups=1001(t0rrant),27(sudo)
t0rrant@testing:~$ id root
uid=0(root) gid=0(root) grupos=0(root)
t0rrant@testing:~$

t0rrant@testing:~$ ls
Desktop Documents Downloads Images Music Videos
t0rrant@testing:~$

t0rrant@testing:~$ ls Images/
dontpanic.jpg
t0rrant@testing:~$

t0rrant@testing:~$ ls -a
.              .bashrc    Downloads  .profile
..             Desktop    Images     Videos
.bash_history  Documents  Music
t0rrant@testing:~$

t0rrant@testing:~$ ls -l
total 24
drwxr-xr-x  2 t0rrant t0rrant 4096 May 13 23:58 Desktop
drwxr-xr-x  2 t0rrant t0rrant 4096 May 13 23:58 Documents
drwxr-xr-x  2 t0rrant t0rrant 4096 May 13 23:58 Downloads
drwxr-xr-x  2 t0rrant t0rrant 4096 May 13 23:58 Images
drwxr-xr-x  2 t0rrant t0rrant 4096 May 13 23:58 Music
drwxr-xr-x  2 t0rrant t0rrant 4096 May 13 23:58 Videos
t0rrant@testing:~$

t0rrant@testing:~$ touch myfile
t0rrant@testing:~$ ls -l
total 24
drwxr-xr-x  2 t0rrant t0rrant 4096 May 13 23:58 Desktop
drwxr-xr-x  2 t0rrant t0rrant 4096 May 13 23:58 Documents
drwxr-xr-x  2 t0rrant t0rrant 4096 May 13 23:58 Downloads
drwxr-xr-x  2 t0rrant t0rrant 4096 May 13 23:58 Images
drwxr-xr-x  2 t0rrant t0rrant 4096 May 13 23:58 Music
drwxr-xr-x  2 t0rrant t0rrant 4096 May 13 23:58 Videos
-rw-rw-r--  1 t0rrant t0rrant    0 May 14 00:05 temp
t0rrant@testing:~$

t0rrant@testing:~$ echo Hello World
Hello World

t0rrant@testing:~$ echo Hello World > temp
t0rrant@testing:~$

t0rrant@testing:~$ cat temp
Hello World
t0rrant@testing:~$

t0rrant@testing:~$ cat temp
Hello World
t0rrant@testing:~$ echo Hello World! > temp
t0rrant@testing:~$ cat temp
Hello World!
t0rrant@testing:~$ echo Goodbye World! >> temp
t0rrant@testing:~$ cat temp
Hello World
Goodbye World
t0rrant@testing:~$

t0rrant@testing:~$ history
     1 whoami
     2 groups
     3 id
     4 ls
     5 ls -a
     6 ls -l
     7 touch myfile
     8 ls -l
     9 echo Hello World
    10 echo Hello World > temp
    11 cat temp
    12 cat temp
    13 echo Hello World! > temp
    14 cat temp
    15 echo Goodbye World! >> temp
    16 cat temp
    17 history

t0rrant@testing:~$ !1
whoami
t0rrant
t0rrant@testing:~$

t0rrant@testing:~$ !1
whoami
t0rrant
t0rrant@testing:~$ !!
whoami
t0rrant
t0rrant@testing:~$

t0rrant@testing:~$ man ls
LS(1)                            User Commands                           LS(1)

NAME
       ls - list directory contents

SYNOPSIS
       ls [OPTION]... [FILE]...

DESCRIPTION
       List  information  about  the FILEs (the current directory by default).
       Sort entries alphabetically if none of -cftuvSUX nor --sort  is  speci‐
       fied.

       Mandatory  arguments  to  long  options are mandatory for short options
       too.

       -a, --all
              do not ignore entries starting with .

       -A, --almost-all
              do not list implied . and ..

       --author
 Manual page ls(1) line 1 (press h for help or q to quit)
t0rrant@testing:~$

Variables

A variable is a "word" you can assign a value to. Shell variables are defined in uppercase, by convention. Bash has two types of variables:

• Global (or environment) variables
• Local variables

Global variables are available in all Bash sessions, they can be displayed using the env command. These variables contain information that should be persistent across all shells, such as:

• the user running the shell, USER
• the name of the machine the shell runs in, HOSTNAME
• the path for the current working directory, PWD
• the path for the previous working directory, OLDPWD
• the language used by the system, LANGUAGE
• the path for the shell executable we are running, SHELL

Local variables are words specific to an execution environment. What this means is that if you define a variable in one Bash session, it is not available to another Bash session. They are also displayed with the env command, mixed with the environment variables.

Apart from dividing variables in local and global variables, we can also divide them in categories according to the sort of content the variable contains. In this respect, variables come in 4 types: [9]

• String variables
• Integer variables
• Constant variables
• Array variables

In order to simplify this subject we will focus on String and Integer variables only.

To assign a value to a variable, in a shell, we do the following:

t0rrant@testing:~$ MYVAR="myvalue"
t0rrant@testing:~$

We should not put spaces around the equal (=) sign, as it will cause the shell to error. It is also a good practice to always surround our String variables with quotes in order to reduce our chances of making errors.

To access a variable's value we use the dollar ($) sign in the form $VARNAME

t0rrant@testing:~$ echo $MYVAR
myvalue
t0rrant@testing:~$

In the case of local variables defining a variable in the form VARNAME=value make the variable only available to the current shell, but not to applications or processes that are child processes of that shell.

t0rrant@testing:~$ bash -c echo $MYVAR

t0rrant@testing:~$

In order to make variables available to child processes we need to use the export command.

t0rrant@testing:~$ export MYVAR="myvalue"
t0rrant@testing:~$ bash -c echo $MYVAR
myvalue
t0rrant@testing:~$

Besides defining and displaying variables, we can interact with variables in interesting ways.

We can concatenate strings:

t0rrant@testing:~$ HELLO="Olá"
t0rrant@testing:~$ WORLD="Mundo!"
t0rrant@testing:~$ HELLOWORLD="$HELLO $WORLD"
t0rrant@testing:~$ echo $HELLOWORLD
Olá Mundo!
t0rrant@testing:~$

We can do arithmetic operations with Integers by surrounding our operation with $(( ... )):

t0rrant@testing:~$ ONE=1
t0rrant@testing:~$ RESULT=$(($ONE+$ONE))
t0rrant@testing:~$ echo $RESULT
2
t0rrant@testing:~$

We can mix it all up:

t0rrant@testing:~$ ONE=1
t0rrant@testing:~$ RESULT=$(($ONE+$ONE))
t0rrant@testing:~$ QUESTION="One plus One"
t0rrant@testing:~$ echo $QUESTION is $RESULT
One plus One is 2
t0rrant@testing:~$

Shell arithmetic is complex and is not the focus of this section, if you would like to know more see the official documentation on the subject.

File Editing

One thing we have not covered yet is how to edit files. In Linux you have a lot of different options, be it a Graphical User Interface (GUI) or Command Line Interface (CLI) applications. If you talk to one user you will ear Vim, of course , it's very powerful, others will say Use Emacs, it's the best and most powerful!, well ... I say Use whatever tool you have the time to learn, and trust me when I say those two take some time to learn. I rather start off with something more simple and straight forward. However, if you would really like to know about those two and other CLI text editors you should check openvim and gnu pages.

In Ubuntu 20.04 you should have the following applications available:

• nano (CLI)
• gedit (GUI)

The most familiar for you to use is probably gedit as it is a windowed application where you can use your mouse to move around and scroll the file.

In this course I will focus on using the CLI, so we will be using nano in our examples.

nano is very simple, you execute the command with the name (or path) of the file you want to edit. If it exists, it is opened and you can edit it. If it does not, it is created.

Every command in nano is a combination of the CTRL key (indicated by ^ in the instructions) or the ALT key (indicated by M- in the instructions) followed by the shortcut key.

For example, let us create a file called test, write something in it, save it and exit.

t0rrant@testing:~$ nano test

  GNU nano 4.8                                    test
|



























^G Get Help   ^O Write Out  ^W Where Is   ^K Cut Text   ^J Justify    ^C Cur Pos    M-U Undo
^X Exit       ^R Read File  ^\ Replace    ^U Paste Text ^T To Spell   ^_ Go To Line M-E Redo

On the first screen line we have the application name and our file name. On the second line is where our file contents start, where we see a blinking cursor is just like the one in the terminal.

On the bottom we have some helpful commands. After we wrote something in our file we would save by pressing the CTRL+O combination:

  GNU nano 4.8                                    test                              Modified
Hello World!


























File Name to Write: test|
^G Get Help              M-D DOS Format           M-A Append               M-B Backup File
^C Cancel                M-M Mac Format           M-P Prepend              ^T To Files

The cursor is now on the bottom, so we could save the file with another name if we wanted, so we press Enter to confirm, to which the application replies how many lines it wrote:

  GNU nano 4.8                                    test
Hello World!


























                                          [ Wrote 1 line ]
^G Get Help   ^O Write Out  ^W Where Is   ^K Cut Text   ^J Justify    ^C Cur Pos    M-U Undo
^X Exit       ^R Read File  ^\ Replace    ^U Paste Text ^T To Spell   ^_ Go To Line M-E Redo

Now we exit by pressing CTRL+X.

If we had not saved the file before exiting, nano would ask us if we wanted to save the file, and we would type Y or N and press Enter, which would be followed by a prompt to choose the filename if we typed Y.

Scripting in Bash

Like we saw in File Types, in Linux the beginning of a file is what tells us the type of the file and even what application the file is supposed to be executed with. For Bash scripts we always start the file with a shebang (#!) followed by the path to the env command and bash as its argument

#!/usr/bin/env bash

Imagine we want to create a file named test.sh which should display our username, relative path to itself, and the name of the machine it is running on, its content could be:

1
2

#!/usr/bin/env bash
echo I am $USER, and I just ran $0 at $HOSTNAME

After saving the file and closing nano we need to make that file executable (remember File Attributes and Ownership):

t0rrant@testing:~$ chmod 755 test.sh

And execute it, by indicating a path to the file:

t0rrant@testing:~$ ./test.sh
I am t0rrant, and I just ran ./test.sh at testing

Network Communication

Network devices communicate with each other in a way that resembles a very awkward and very formal conversation.

Comparing a network communication to a human conversation between Alice and Bob, it could go something like this:

As you can see for every statement Alice makes, Bob acknowledges that statement, and there are two distinct protocols for initiating and terminating a conversation.

With network devices we need:

1. a way to identify a device
2. a way to reach a specific device
3. a way to represent a message
4. a way to represent which service in the device we want to deliver the message to

The first is called a Media Access Control (MAC) address, and is a unique identifier assigned to every Network Interface Controller (NIC).

The second is called an Internet Protocol (IP) address, and is a numerical assignment for a specific device. For simplicity we will only consider IPv4 addresses which are made up of four numbers, ranging from 0 to 254 and are separated by a dot (.) (i.e: 192.168.0.254).

The third is called a packet, and is what devices send to each other through the network. Each message exchanged between devices can be very small or very large, so these messages may need to be broken down into smaller packets, this is done by each network device.

The fourth is called a network port, and it usually identifies a process or network service waiting for messages (listening). This is a software port, a physical port is where physical cables connect to.

Imagine the IP address as being an address for a certain store in a mall, but it just identifies the building, the port identifies the number of the actual store, the actual endpoint where you can find your wanted service. You would not be going to an electronics store asking for beer right? =P

So, every network packet, should have a source IP address with its port and a destination IP address with its port in order to know where to exactly send the message to and where we expect to be replied to. This is very similar to traditional mail, just more complicated than sending a letter.

The MAC address association with an IP address also exists, but it is treated only within the local network and that is a whole other subject(s).

Switching

To filter and deliver these packets to its correct destination we have the network switch, which connects several network devices and "knows" where to which port to send each packet that arrives at another port.

In Figure 6, we can see an example of a switch with four connected devices. Each device will have a network interface connected to one of the switch's network ports (or the wireless interface) and the switch will know which IP address is associated with which MAC address. In example, if a packet arrives to the switch that has the TV's IP address as destination, only the TV will receive that packet.

Network Switch forming a network of devices

So, having a switch with connected devices defines a network between those devices.

Routing

In our home router we have a modem that connects to our ISP and gives us access to the Internet, but that modem will not do much more by itself, it is just a way to make a path to the ISP.

To have our packets being forwarded to the Internet we need the router.

The main functions of a router are:

• connecting multiple networks
• forwarding network packets

In Figure 7 we can see an example of two networks connected through the Internet. Every network that connects to the Internet will usually follow this setup.

Two networks connected by routers through the Internet

Our local router makes it possible to connect from our to a different network connected to another router, or a different network connected to the same router.

Sending a packet from our device with a local IP address to another device in a different network is made possible due to a process called Network Address Translation (NAT). I will not delve into it here, but broadly speaking it is a way for your router to hide your device information, exposing only itself in any forwarded packet, while at the same time maintaining a record of the origin for each forwarded packet in order to deliver any response to their proper recipient.

DNS

The Domain Name System (DNS) works somewhat like an old phone list. It is a dynamic set of servers that have records corresponding, among other record types, names to IPv4 addresses (Alias or A records). For example, the name implement.pt matches the A record corresponding to the IPv4 addresses:

• 104.24.106.10
• 104.24.107.10
• 172.67.136.196

which corresponds to three different entry points to access this name.

This record keeping is recursive, meaning that when you contact a certain DNS server it will search its own records for a match, and if it fails to find a match it will ask that information to another DNS server. This goes on until either a record is found, returning it back to the user, or no more DNS servers are available to ask to, in which case something like a "I do not know that record" is returned.

Taking a look at Figure 8 we can see an example of what happened when the device you are using to access this article tried to reach implement.pt.

DNS request flow example

First your device searched its internal records, and probably did not find anything.

Then it asked the next DNS Server, which is usually your router.

Your home router should also not have any records for implement.pt, and if so it asked its default DNS Servers for it. Usually these are your ISP's DNS servers. If they also do not have any record they will ask another, and another, until eventually some DNS server replied with the answer "implement.pt. A 104.24.107.10" and voilá your router can now pass that response to your device, which it did or else you would not be reading this =).

After your device has this information it can finally connect to the server at the correct address and initiate communication with this server at a specified port, in this case port 443.

Symmetric vs Asymmetric Cryptography

Today’s crypto systems are divided into two categories: [15]

• symmetric
• asymmetric

Symmetric cryptography uses the a unique key (the secret key) to encrypt and decrypt a message. We can view this as a simple lock which only opens with a correct key, like we can see in Figure 9

Symmetric cryptography analogy

Asymmetric (or public key) cryptography uses one key (public key) to encrypt the message and a different key (private key) to decrypt the message. [15] One of the advantages is that there can be unending copies of the public key without compromising the private key.

By far the best non-technical explanation I have seen was shared by Panayotis Vryonis in his blog and I will share it here with you.

Picture a box with a lock, but this lock is special (see Figure 10). It fits two separate keys (yes, two). The first one can only turn clockwise (from A to B to C), let us call this the private key, and the second one can only turn counter-clockwise (from C to B to A), let us call this the public key. [10]

Asymmetric cryptography analogy

With this we can do two things to an unlocked box:

• lock with the private key
• lock with the public key

If we lock with the public key, only the person with the private key will be able to open it, and so anyone with the public key will be able to send secret items safely inside the box, knowing that only the owner of the private key will be able to access them.

If we lock the box with the private key, anyone that has the public key and can open the box can be sure that the box was locked by whoever possesses the private key counterpart, which makes them sure that whatever is inside the box it was placed by the one person holding the private key.

For example, Bob has one of these specials boxes, keeps one copy of the secret key for himself, and makes lots of copies of the public key. He then spreads those copies around, his house, office, random mailboxes, subway, and gives copies to all of his friends, including his close friend Alice.

Alice wants to send a secret message to Bob. She has a box with this special lock made by Bob. She can put a message inside the box and turn the lock to the locked position A. Then she can pass the box to anyone (that will eventually deliver the box to Bob, of course) sure that only Bob will be able to use his secret key to move the lock to the unlocked position B.

Now imagine that Alice receives a box from someone, saying it has a message from Bob. But how can Alice be sure it was Bob that sent it? Easily enough, if the public key that Bob gave her can open the box then the box surely came from Bob.

Secure Shell (SSH)

The SSH protocol (also referred to as Secure Shell) is a method for secure remote login from one computer to another. It provides several alternative options for strong authentication, and it protects the communications security and integrity with strong encryption. [12]

SSH protocol [12]

When using SSH, we are using the same concepts we saw earlier about asymmetric cryptography. As we can see in Figure 11, the SSH Client first contacts the SSH Server through an insecure communication channel (the network), so after the SSH Server sends the Client its public key, they use a really crafty way of having a common secret without anyone in that insecure channel being able to know what it is. [14]

In Figure 12 we can see an analogy of this ingenious process, of sharing secrets through an insecure channel, with colors instead of very large numbers (which is what roughly happens in a real-world interaction), this process is called the Diffie-Hellman Key Exchange.

Sharing a common secret through a non-secure channel [13]

The process begins by having the two actors, Alice and Bob, agree on one color that does not need to be kept secret. In this example, the color is yellow.

Each of them also has a secret color that they keep to themselves, in this case red for Alice, teal for Bob.

The crafty part of the process is that Alice and Bob each mix their own secret color together with their initially shared color (yellow), resulting in an orange-tan color for Alice and a light-blue mix for Bob.

They can now exchange the resulting mixed colors publicly, we assume that separating the mixed colors back to their original individual colors takes too long and is very expensive.

Finally, they each mix the color they received from the previous exchange with their own secret color.

The final result is a color mixture (yellow-brown in this case) that is identical for both.

If someone saw the exchange, they would only know the common color (yellow) and the first mixed colors (orange-tan and light-blue), but it would be extremely difficult for them to know the resulting secret color (yellow-brown).

Bringing the analogy back to a real-life exchange using large numbers instead of colors, this determination is computationally expensive. It is impossible to compute in a practical amount of time. [13]

Finally, after this "simple" key exchange the SSH Client and Server are ready to communicate securely.

Server Application Setup

First let us install the server application:

t0rrant@remote-server:~$ sudo apt install openssh-client openssh-server

And now we can start the service

t0rrant@remote-server:~$ sudo systemctl start ssh

see that it is running

t0rrant@remote-server:~$ sudo systemctl status ssh
● ssh.service - OpenBSD Secure Shell server
     Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled)
     Active: active (running) since Mon 2020-05-11 15:24:03 WEST; 5s ago
       Docs: man:sshd(8)
             man:sshd_config(5)
    Process: 9523 ExecStartPre=/usr/sbin/sshd -t (code=exited, status=0/SUCCESS)
   Main PID: 9524 (sshd)
      Tasks: 1 (limit: 38302)
     Memory: 1.4M
     CGroup: /system.slice/ssh.service
             └─9524 sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups

mai 11 15:24:03 testing systemd[1]: Starting OpenBSD Secure Shell server...
mai 11 15:24:03 testing sshd[9524]: Server listening on 0.0.0.0 port 22.
mai 11 15:24:03 testing sshd[9524]: Server listening on :: port 22.
mai 11 15:24:03 testing systemd[1]: Started OpenBSD Secure Shell server.

and from our workstation test the connection:

t0rrant@testing:~$ ssh t0rrant@192.168.1.11
t0rrant@odin's password:
Welcome to Ubuntu 20.04 LTS (GNU/Linux 5.4.0-29-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/advantage

  System information as of Mon May 11 15:25:44 WEST 2020

  System load:           0.6
  Usage of /:            22.3% of 9.32GB
  Memory usage:          35%
  Swap usage:            0%
  Processes:             102
  Users logged in:       0
  IPv4 address for enp3s1: 192.168.1.11

0 updates can be installed immediately.
0 of these updates are security updates.


To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.

t0rrant@remote-server:~$

SSH Keypair Setup

Entering our password every time we connect to a remote server is more than tedious, it opens the possibility for someone else to be able to "guess" our password. Of course we can find ways to remedy this, we can generate a random password with 20+ characters, we can setup defense mechanisms to "lock out" anyone that fails to enter the correct password some number of times, some other convoluted solution or we could gather the knowledge we gained from secure communications and SSH and make use of asymmetric cryptography not only to perform secure communications, but also to authenticate ourselves with the server.

Remember that section, and remember that if our "box" was locked with our public key, it can only be unlocked with our private key, so if the server would send a message encrypted with our public key we could only send back the same message if we have the correct private key. Essentially what we are doing is receiving one "box" locked with our public key, unlocking it with our private key, and finally we send a new "box" to the server locked with the server's public key, which we have because the server sent it to us on our first connect (as seen in Figure 11).

In Figure 13 we can see a sequence of this process.

So, let us get on to generating the keys for our special lock =)

When we installed openssh-client it also came with a couple of useful tools, one of them is ssh-keygen, which conveniently lets us generate a pair of keys:

t0rrant@testing:~$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/t0rrant/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/t0rrant/.ssh/id_rsa
Your public key has been saved in /home/t0rrant/.ssh/id_rsa.pub
The key fingerprint is:
SHA256:ILvTwLzlzZyMS7YFflmMY+WxCG7BjkN4VCRg5tae3WI t0rrant@testing
The key's randomart image is:
+---[RSA 3072]----+
|  +.ooo          |
| + + o           |
|  + = =   o      |
| . * O = * o     |
|    X E S =      |
|     % X =       |
|    + B X        |
|     + =         |
|      o          |
+----[SHA256]-----+

One other tool is ssh-copy-id, which adds our public key to a server, for a specific user (the one we connect with):

t0rrant@testing:~$ ssh-copy-id t0rrant@192.168.1.11
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: ".ssh/id_rsa.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh 't0rrant@192.168.1.11'"
and check to make sure that only the key(s) you wanted were added.

t0rrant@testing:~$

Let us try a new connection from our testing workstation to our remote-server:

t0rrant@testing:~$ ssh t0rrant@192.168.1.11
Welcome to Ubuntu 20.04 LTS (GNU/Linux 5.4.0-29-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/advantage

  System information as of Mon May 11 15:34:40 WEST 2020

  System load:           0.6
  Usage of /:            22.3% of 9.32GB
  Memory usage:          35%
  Swap usage:            0%
  Processes:             102
  Users logged in:       0
  IPv4 address for enp3s1: 192.168.1.11

0 updates can be installed immediately.
0 of these updates are security updates.


Last login: Mon May 11 15:25:44 2020 from 192.168.1.10
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.

t0rrant@remote-server:~$

Notice that this time it did not ask us for our user's password, success :)

Now that we have access through our keypair, we can configure the server to not accept password based logins, only accept keypair based ones.

Open (as root) the /etc/ssh/sshd_config file for editing

t0rrant@remote-server:~$ sudo nano /etc/ssh/sshd_config

search for the options PubkeyAuthentication and PasswordAuthentication and change them to yes and no, respectively, as so:

PubkeyAuthentication yes
PasswordAuthentication no

make sure none of those lines start with a #, if they do remove it.

Save and exit by pressing CTRL+O and then CTRL+X.

Finally, restart the application

t0rrant@remote-server:~$ sudo systemctl restart ssh

do not lose or share your private key, and do not forget the passphrase!

Network Interactions

Now that we have a functional client-server connection, what can we really do with it?

First of all, we are getting pretty tired of typing the remote-server IPv4 address, it would be way better if we could simply do

ssh remote-server

and we can! Recalling the network name resolution in the previous section on DNS, when we search for the IPv4 address of a specific hostname, the Linux operating system does not go straight to the DNS servers asking for it. It actually has an internal name resolver which, among other things, reads information from a special file located at /etc/hosts. There we can define our own records, that can be (almost) whatever we want.

If you check its contents (for the sake of simplicity we will ignore IPv6 settings):

t0rrant@testing:~$ cat /etc/hosts
127.0.0.1 localhost
t0rrant@testing:~$

you can see that the name localhost is an alias for the 127.0.0.1 IPv4 address, which is that special address we discussed earlier in Networking 101 that represents our own machine.

As easily as that, we can add an entry for our remote-server, using nano, which leaves the file as such:

t0rrant@testing:~$ cat /etc/hosts
127.0.0.1 localhost
192.168.1.11 remote-server
t0rrant@testing:~$

Note that the hyphen (-) is the only non-alphanumeric character allowed in a hostname (for more information see the man pages for hostname)

And now we can connect to remote-server without typing its IPv4 address:

t0rrant@testing:~$ ssh t0rrant@remote-server
Welcome to Ubuntu 20.04 LTS (GNU/Linux 5.4.0-29-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/advantage

  System information as of Mon May 11 15:56:12 WEST 2020

  System load:           0.6
  Usage of /:            22.3% of 9.32GB
  Memory usage:          35%
  Swap usage:            0%
  Processes:             102
  Users logged in:       0
  IPv4 address for enp3s1: 192.168.1.11

0 updates can be installed immediately.
0 of these updates are security updates.


Last login: Mon May 11 15:34:40 2020 from 192.168.1.10
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.

t0rrant@remote-server:~$

Besides connecting to our remote server and interacting with it from within a shell, we can also do other types of operations through SSH.

We can send a file:

t0rrant@testing:~$ scp test.sh remote-server:~/test.sh
test.sh                                       100%  278     1.2MB/s   00:00
t0rrant@testing:~$

We can retrieve a file:

t0rrant@testing:~$ scp remote-server:~/test.sh test2.sh
test.sh                                       100%  278     1.2MB/s   00:00
t0rrant@testing:~$

We can run commands remotely:

t0rrant@testing:~$ ssh remote-server ~/test.sh
I am t0rrant, and I just ran /home/t0rrant/test.sh at remote-server
t0rrant@testing:~$