LPI 101-500 – 110.3: Protecting data with encryption part 1

1. ssh, scp

In the professional environment, you will have to access remote servers every day. Nobody sits with a keyboard directly on the relevant server. These are more likely to be located in internal or external data centers. And we as administrators access the server from our office via the network to carry out certain tasks. So we need a program that allows us to access other servers over the network. In the past, such things were done with a Telnet program. Telnet is hardly used today because it does not encrypt the connection to the server. Telnet is too insecure for today’s needs. We use the Ssh program instead. Ssh stands for Secure Shell. Ssh has been version two since 1996, and this version is still used today.

So with Ssh, we can connect to a server in the network and work on it. In order for this to work, the so called Ssh server must be installed on the server. Otherwise no connection can be established. Let’s try it out by simply starting a second virtual machine. I’ve already done that in the background and then trying to connect via Ssh. In this case, the command is very simple ssh Server name or Ssh Server IP address. So I would use the IP address Ssh. And the regarding IP address is 192, 168, 178 and 58. That’s the whole command. And from the error message we can already see that this does not work as expected. So let’s install the Ssh server on the server. The package is called Open Ssh Server.

So let’s switch to the other server. Or maybe I will do it like this. So when I have both virtual machines on one screen, on the left side there is my normal my life virtual machine that I have used over the entire course. And on the right side you can see it here on the host name ubuntu Server. This should be my server. And here I have to install the OpenSSH server. Pseudo apt install Opensssh Server so the Ssh server is installed. Let’s see if it started automatically systemctl status and the service name is Sshd. So the Ssh service already running. Okay, let’s repeat the test from just now. Ssh and the IP address. And now it looks different. We get a small warning that says that the authenticity of the server cannot be determined because the server is not yet known to the client.

The server authenticates itself to the client with a key. The key is called the host key, the so called fingerprint. So here, this is the fingerprint. Here of the host key is also displayed. And we are asked whether we are sure that we want to establish a connection to this server. Of course, we confirm that with yes. And we get another message that the relevant server has been added to our list of known hosts. Here. Warning permanently added disappearance to the list of known hosts. So strictly speaking, the host key of the server was entered in the file and saved, which is why we will no longer receive this warning the next time we try to connect, but more about encryption later.

We have to enter our password here and then we should be connected to the server that did not work. Let’s try it again. And now it works. So sorry for the two times wrong password. Now it works and you can see it here. Welcome to ubuntu. The progress is such a it’s just a welcome message. Ubuntu comes with absolutely no warranty and so on. And here you can see Ubuntu server. The host name is Ubuntu Server. And here on the right you see the host name. Here is Ubuntu Server. And on the left our host name is Virtualbox. So that’s different now. And because of that we are sure that we are now locked in to this server here. And now we can work on this console, so we can work on this server as if it were our own local computer.

In addition, we can only use this command if the user name I am currently locked in with also exists on the target computer. Otherwise we have to explicitly specify a different user. But more on that in a moment. So I can see my files. I can do whatever I want here to log off or to look out of the server. I just use exit and here connection closed and you see our old host name or virtualbox hostname and we are back on our local system. Normally as an administrator you have at least two different identities in the network the user identity with which you work normally on your local PC, and the administrator identity that you use when you have to administer something on a server. Accordingly, you may use ssh as a normal user, but want to log into the server with your admin identity.

This is also no problem at all with Ssh we simply tell Ssh that we want to connect as user A, user B and so on. I created another user called admin locally on my system. Let me show that admin. And you see here that’s the user admin. I’m logged in at admin now, so the user exists and now I want to connect to the server. So to this server here as admin here we would use the following command ssh admin at and then the IP address of this server here. And then it was 58. I think we have to type in the password. And now we see that the access was denied here. Why? Because the user admin does not exist on the server and would have to be created there. First you have to keep in mind that local users are rarely used in a large company network.

But corresponding users apply system wide, so keyword, active directory or LDAP. In our little test, of course I only use local users, so I just create the user admin on the server test admin and then the name admin. Now I choose a password for admin. Okay, now the user admin is created on the server. I have assigned a password and now let’s try to establish a connection again with the same command as stage admin at and then the IP address. And this time it works. See, we are locked again here at our Ubuntu server. We have our welcome message here and that’s it. By the way, the password of the user admin who is installed on the server is requested when the password is requested, not the password of the admin of the client.

Strictly speaking, a user admin is not even necessary on the client. Actually it just needs to be installed on the server. So we verify at once. And then let’s delete our user admin on our local computer. So use pseudo user dell admin sorry, again the wrong password. Okay, the user should be deleted. Now let’s try it out user does not exist. And then let’s connect again to the server with the user admin with ssh l admin and then the IP address. By the way, this is the other notation of the command that we can use. We can use the notation with the at so ssh admin at and then the IP address or SSHL DL stands for login and then the username and the IP address. Both versions are correct password and we see that we are connected.

So it works as we want it. We are disconnecting again with exit. Ssh always runs on port 22 by default and both the ssh server and the client are configured accordingly. If the ssh port on a server is set to 3000, for example, we can also specify a port number for the ssh connection to connect us. To do this we use the option p. So for example SSHP and then 3000 and then the IP address and so on. Of course p stands for port here. Alternatively we can use the o option to specify the port with ssh o port and then 3000 and then the IP address or the hostname. The option o can be seen in detail in the main page. Of course. Also other options of ssh we can also copy files to the server. We use the scp command for this. So let’s create a little test file for this touch scp test.

And now I copy this file to a specific directory on the server. I don’t know we have a test directory here. And you see we have some files here because this is a clone of this one here. So we have the same files here, but you can see we don’t have an STP test file here in this directory. So this is only here. And now let’s copy it to the server with the following command scp then we want to copy the scp test file with the user manual at and the appearance 58. And now we have to use a colon. And then we can use a path home test and we get a success message. Let’s see on the server whether the file has has really arrived. So again, ll and here you can see our SAP test file. So it worked.

2. ssh_conf, sshd_conf

Let’s get back to Ssh. First, let’s take a look at the main configuration file from the Ssh server. This is the file at Cssdconfig. Keep in mind that the Sshd config file is the configuration file for the Ssh server. There is also an Ssh config. So Ssh without D. That relates to the Ssh client. I have to use pseudo. Of course, there are quite a few settings here, but most of them are initially commented out. For example, we can set the port that the Sh server should use, or the IP address that should be used. So if we enter the current IP address of my Ubuntu server here, ssh will continue to function normally. Since my notebook is assigned to its IP address via Dhcp, it is possibly that I have a completely different IP address after the next restart.

Then the Ssh server would no longer work. We can test that out. So I would change or I would enter simply enter an IP address here. I would comment that in and I use the IP address of my Ubuntu server. And if you remember from the last lesson, it is 192, 168, 178, 58. We have to restart the server once the Ssh server wants, not the whole server system. Ctl restart sshd. That’s it. So let’s see if the Ssh connection still works. That looks good. The connection continues to work. Now let’s change the IP address on the server to any other one. So maybe 59. And then we have to restart the Ssh server again. And you see, the restart has already an error message job for Ssh service failed because the control process exited with error codes.

That’s because the IP address we have entered is not correct. So the IP address is not available for the server. So we cannot even start the Ssh server. So we have to change it back to 58 and then let’s restart it again. And now it should work. Let’s try it again. I’m still connected here and it is working again. There are of course other interesting settings in the file. For example, scroll a little bit down, maybe this one here the permit route login option. So whether you can log in as route or not here, maximum sessions or login attempts you can use, or maximum sessions that can be set here. We can set corresponding encryption methods and so on, but more on that in the later lesson.

Another important file is the etsy Ssh config file. Again, the note at this point we just talked about the Sshd config, the configuration file for the Ssh server. Now let’s talk about the Ssh config without D and the configuration for the Ssh client takes place here. So we switch to the left one and VI scss config. This file has a similar structure to the Sshd config here too, there are already various preset settings that we only have to activate by removing the hash at the beginning of the line. Here we have the option to specify whether x eleven redirect should be allowed on the client side or not. By the way, an x eleven forwarding is a way of starting a graphical application on a remote server so that it is then opened on my local computer.

So theoretically I could start open office on the server and edit it on my computer. The display variable is then automatically set on the target system. We also have options such as such as switching password, authentication on or off or activating or deactivating certain encryption methods and so on. Other important files for Ssh are the previously discussed Etsy hosts allow and Etsy host deny files. Here you can control who is allowed to use Ssh and who is not. Ssh can also be completely prevented using the Etsy no login file discussed above. Local login and Ssh no longer work here. Th.

3. ssh-keygen, encryption methods

Now we come to the most important part of Ssh, namely encryption. We had already made several connections with Ssh. With our first connection, the host key of the Ssh server was entered in our file known hosts. So we will take a look with the dot. So it’s hidden and then known host. So here we see the corresponding host key or several host keys, depending on which and how many servers we have already connected to IR ssh. So in this case we only have one host key. Here we can also look at these host keys with the ssh key gen tool. So let’s take a quick look at the man page. Ssh keygen ssh keygen openssage authentication key utility ssh keygen generates, manage and converts authentication keys for Ssh.

To view the host key or the fingerprint with ssh keygen, use the l option for list followed by the F option for file ssh keygen LF and then again our path to the known host and of course the known host file. And here you can also see the corresponding host key. There is another file that does the same as the file known host, which is always located in a user’s personal home directory in the Sh subdirectory. As we have seen here, this file is called ssh known host, and if it exists, it is located in the Etsy ssh directory. So normally in Etsy ssh and then Ssh known hosts, this file is not available on my Ubuntu by default, but it would have the same content as the known host file, but it would apply globally for every user.

And this file here known hosts with this key here, this is only active for my user, for my user account. So make yourself aware that the file with the name known host exists in the home directory of a user which contains the host keys of the Ssh server with which this user has already connected. And that, on the other hand, there can be a file ssh known host which is located in the directory at CSSH. The host keys of all users who have used the system for Ssh are stored there. Or maybe that was put a little wrong. It is not the host keys of the user, but the host keys of the server with which different users have connected. Okay, let’s change my system here.

I want to switch to the system where the Ssh server is installed. Okay, I’m now logged on to my second virtual machine. You can see it here on the host name Monroe server. And here let’s change to the At CSS directory at CSSH. Here we see different types of keys that can be used to protect the Ssh connection. We have the encryption type EC, DSA Ed 2551, 119 and RSA here. In older versions, the encryption type DSA was still integrated. But since this is considered out of date and also has a known weakness, it should no longer be used. EC DSA is standard in most current distributions but is currently suspected of having weaknesses similar to those of DSA. Ed two five 5119 is very similar to Ecdsa but without the known weakness.

Since Edw 5519 is only supported by the latest Ssh versions, problems could arrive here, arise here if you have older systems in the network. Last, but not least, RSA. RSA is established and supported everywhere. If we look at the file names, we can see that there are two different files for each type of encryption. A file namely the one without the Pub extension. So this one here always contains the so called private key and a file with a Pub extension which stands for public contains the public key. How does it work with a private and the public key? First of all, the keys are there to authenticate between server and client when establishing the connection by default via port 22 the client requests the public key from the server or has even received it beforehand.

The client can use this public key to encrypt the session key generated when the connection is established with the help of the private key, the server can decrypt this encrypt session key again. Now both systems can communicate with each other via Ssh. With the help of Ssh keygen we have just learned about, we can generate new host keys. For example, if you want to create a new key pair for RSA encryption method, we could use the following command pseudo Ssh keygen and then for example b 40 96 TRS a so with the option B, I specify that the key should be 40,096 bits. The T option lets me choose the encryption type, in this case RSA.

I have to use my password of course. And here you can see generating public private Rsr key pair. And now we are asked we should enter a key or a path and I would use this one here. At CSSH is my path and my key name is sshhost RSA key. And you see it is exactly the same path and the same key name as already exists. And here I get the confirmation this file already exists. Overwrite yes, I want to override it. And now we are asked for a passphrase. In any case you should enter a password here as this will also encrypt the created file. Again, without a passphrase the key would be visible in plain text phrase and again and now we are shown the keys fingerprint.

Here we see RSA 40,096 bits and we see that we have now two new RSA files. So look at the timestamp. It’s eleven nine and here the actual time is also eleven nine. So now we have to tell the Ssh server that the new RSA key should be used. To do this we added the At Cssshd config. So this one here bi sorry Sshd config. And here we can enter the corresponding RSA key because we have used the exact same path here and the exact same name. I’m very sorry, I have forgotten to use pseudo again. So now I can only comment that in. So this is now active host key as CSS RSA key. So this key that we have just created, now we have to restart the Ssh server.

Okay, it is restarted. And now I think we should switch back to the other system. And now let’s try to connect again with Ssh and then the IP address and you can see we get a message that the key is wrong or that it has changed here. Warning remote host identification has changed. It is possible that someone is doing something nasty. And then some warnings here we have a fingerprint here for the RSA key that we have just activated. So we cannot connect. But the error message also tells us how we can solve the problem. Namely by executing this command here.

Namely or it means removing the old host key from the known host file. So let’s try that out. Simply click, simply copy and paste. And now let’s try it again. And this time it looks like we are running Ssh for the first time. The fingerprint is displayed to us and we can clearly see that it is an RSA key. Yes, we want to connect. Then I have to enter my password. And now I am connected to the server. You can see it on the host name here, which differs from this host name. And that’s it. In theory we could have copied the host key from the server manually into the known host file, but this way also works. So see you in the next lesson.