Often the system we need to connect to is physically somewhere else,
so we have to connect remotely. There are several different ways to do this,
but in this video I’ll show you one of the most common methods by connecting remotely using ssh,
also known as Secure Shell. In this demo, I’ll be working on two systems,
the server that I want to connect to and the client I’ll be connecting from.
Both are running Oracle Linux 8.
Let’s get started by opening a terminal session on the server system.
We’ll need to make sure the system has OpenSSh server installed and configured.
Oracle Linux has this installed out of the box and we can verify that by using dnf list installed
and then piping it to grep ssh. And we see openssh-server listed here.
However, if you needed to install it, you’d use sudo dnf install openssh-server.
After installation, you would then need to enable and start the sshd
daemon, which listens for client connection using sudo systemctl enable --now sshd.
With the openssh-server installed, let’s look at configuring it by editing the sshd_config file.
So I’ll open it up with sudo vi /etc/ssh/sshd_config.
There are a lot of setting you can adjust here. But I'm only going to highlight a few.
Near the top you can set the port that SSH listens on.
By default it’s port 22. If I wanted to change it,
I’d uncomment the line and adjust the port number.
But the default works for my setup so I’ll leave it as is.
If we page down, there’s a line that permits root access.
Generally you’ll want this to be set to no to make the system more secure.
If you needed root access remotely, you would log in with a less privileged user and
then elevate your privileges after you connect.
Which is what I’m going to do, so I’ll set this to no.
Scrolling down, we see a line for allowing key authentication.
Which would allow users to use key pairs to log in instead of passwords.
I’ll show you how to do this later, so make sure this is set to yes.
If we continue down the file, there’s a line for password authentication.
This allows clients to login with a username and password defined on the server system.
If we set it to no, users would have to login using a key instead.
As I mentioned we’ll look at keys later. So for now, I’ll leave password authentication
set to yes and change it once we get keys configured.
Ok I’ll save and quit the file. Since we made changes, we’ll need to restart
the daemon with sudo systemctl restart sshd. Now that we have ssh sever up and running,
we’ll need to make sure the firewall will allow ssh connections.
To do that, we’ll need to open the port that ssh is using.
In this case, it’s using the default port 22, so we can simple add the ssh service
to the firewall with sudo firewall-cmd --permanent --add-service=ssh.
Then reload the firewall with sudo firewall-cmd --reload.
And we can verify the firewall settings with sudo firewall-cmd --list-all.
And ssh is listed as a service. If you were using a different port,
you’d have to specifically open that port with the --add-port option.
[firewall-cmd --add-port=/tcp –permanent]
And depending on your system settings, you may also need
to tell SElinux about the port change. [semanage port -a -t ssh_port_t -p tcp ]
Ok, that’s it for configuring the server, so let’s take a look at
connecting to it from the client system. I’ll switch to the client terminal.
We’ll need to make sure the system has openssh-clients
package installed and configured. Most distros have this installed by default.
And again, we can verify using dnf list installed and then pipe it to grep ssh.
And we see it’s installed on this system. But if you needed to install it, you could
use sudo dnf install openssh-clients. The config file for the client side is
in /etc/ssh/ssh_config and I’ll take a look at it with vi.
This file allows you to set system wide options.
I won’t bother with that now. But just know that the ssh_config file is
for the client side, and the sshd_config file that we looked at previously is for server settings.
Now, let’s connect from the client to the server.
The server already has a user matching my username and password, so I can use that to connect.
I’ll enter ssh my username @ and the IP address or hostname of sever.
If I left it like this, it would assume the default port of 22,
but to specify a port I could use the –p option followed by the port number.
Then it’ll ask if I want to accept the server’s key.
The key is generated by default when installing OpenSSH server.
I’ll enter yes to accept the key and then it’ll ask me for my password.
And now we’re logged into the server system’s terminal.
The same as if I were logged in and sitting in front of it.
For instance, maybe I’ll run ls -la. And we see those files.
This connection will stay open as long as network connectivity is maintained.
So once I’m done working, I can type exit to disconnect and it’ll
return me to the prompt on my client system. In that example, I used a username and password
The other way to authenticate remote connections is using key pairs.
Which is more secure because, unlike passwords, a key can’t be guessed.
It also frees the user from having to remember complicated passwords.
So how do we set up key authentication?
We’ll generate a key pair on our client system using ssh-keygen.
This creates a private key and a corresponding public key
We’ll copy the public key over to the server and keep the private key securely on the client.
Then when we try to connect the system will present our private key.
The server will verify that it corresponds to the public key that's already on the server.
And if it does, the server will allow us to connect.
So let’s try it out. On my client system, I’ll run ssh-keygen.
It’ll ask where to save the file. If I don’t specify anything,
it’ll save to the default .ssh folder within my home directory and call the key id_rsa.
That’s fine for my setup, but if you had several different systems you were connecting to,
you’d probably want to specify something more specific.
I’m not going to add a passphrase, so I’ll just hit enter.
And it generates the keys. And if I run ls –l .ssh, we see
the id_rsa file which is the private key, and the id_rsa.pub file which is the public key.
Now that we have the key pair, we need to copy the public key over to the server.
To do that, I can use ssh-copy-id,
then the -i option followed by the path to the identify file or key.
So in my case it’s my home directory ~/.ssh/id_rsa.pub.
Then a space and my username@the ip address of the server.
It’ll ask for my password and it adds the keys to the .ssh/authorized_keys file
within my home directory on the server. Now let’s connect to the server with ssh
myusername@the ip address then –i and the path to my key.
And this time, notice that it doesn’t ask for my password.
That’s because it’s using key authentication. Now that we’ve added a key,
let’s disable password authentication by opening up the sshd_config file.
And changing the password authentication line to no.
Then I’ll saving and quit the file. Since we made changes to the file,
we’ll need to restart the daemon with sudo systemctl restart sshd.
And let’s exit out of my session, then return to the client.
Let’s test out that password authentication change by trying to log in with a different
user that hasn’t set up a key pair yet. So I’ll try to log in as sam who is a
defined user on the server with ssh sam @ and the IP address.