Join Scott Simpson for an in-depth discussion in this video SSH: Secure access, part of Linux Tips Weekly.
- [Instructor] When we log in to a Linux machine locally, we're using the console, a local text interface that can present a text or graphical shell. But in a connected world where servers live in your data center or in other people's data centers, we often need to log in remotely, rather than by sitting down at a keyboard in front of the machine we need to use. In order to make the connection securely, we use a protocol called SSH or Secure Shell. Support for this protocol needs to be installed on the remote machine, though usually systems configure to servers and have the software preinstalled. Open SSH is a commonly used package, though there are others.
SSH sets up an encrypted connection between the remote computer and a user's local computer. Within this connection, a shell program operates just as it does when you're logged in locally at a console. You can type commands and see the results. The SSH protocol also provides support for transferring files securely, using the SFTP and SCP protocols. We can configure SSH to allow logins to a remote system for all users on that system or only some, and we can choose whether to allow them to log in with their passwords or with a cryptographic key instead.
In this video, we'll take a look at how to set up a server to allow SSH connections, and then I'll connect from another Linux machine. As the series continues, we'll use SSH from other Linux and Windows machines to connect and transfer files. On the system we want to access remotely, we need to make sure that the SSH server is installed. I'll do that here with apt install openssh-server. And just like that, our system is able to host SSH connections, but there's a few things we need to look at before we use SSH.
The first is whether the service is running. SSH is configured to autostart at boot, and it should start when it's installed, but let's make sure. To do that, I'll use systemctl status sshd. Here, I can see it's enabled, which means it'll start at boot, and that it's active and running. Good. If it weren't running, I could use systemctl start sshd to start it up. The next thing to check is whether the firewall is allowing traffic to the SSH server software. SSH runs on port 22 by default.
Here on Ubuntu, I can take a look at my firewall settings with ufw status, and see that it's inactive right now, so I need to add a rule to allow port 22 access. I'll do that with sudo ufw allow 22/tcp, and now I need to restart my firewall with systemctl restart ufw. Now, I'll make sure my firewall is enabled with sudo ufw enable. And then I'll take a look at the status again with sudo ufw status, and I can see that I have a rule allowing access to port 22.
If you're on a different platform or are using a different firewall utility, you'll need to check and make changes accordingly. The next thing to look at here on the SSH server is the configuration file for the SSH service. That's located in the etc/ssh/ subdirectly and it's called sshd_config for a SSH daemon. If you have the SSH client software installed, you'll also have a file called ssh_config, and that's what that one's for. This file contains a lot of options about how the SSH server works.
So scattered throughout the file are some lines that are more interesting to us right now than the others. The port directive tells the daemon which port to run on. By default, it's 22, and I'll leave mine there. It used to be recommended by some people to change this port to a more obscure number to try to hide from malicious actors on the internet. But now whatever port you use, some bot will discover it, so there's not really much point in changing it. We have other better means of protecting the service from attackers, and one of those means is the permit root login directive where we tell the SSH server whether we want to allow the root user to log in over SSH.
It's usually a bad idea to let this be enabled, both because trying to log in as root is a common attack, and because we should never really log in to any machine as a root, because we have tools to let us use the superuser role when we need to. So I'll make sure this is set to no. There are a few other options that you might have in your file that specifically prohibit password and without password. These both do the same thing. They tell the SSH server not to allow root to log in with a password, but a key could still be used. With no however, root is not allowed to log in via SSH using any means.
PubKeyAuthentication determines whether we will allow keys to be used to log in, and I'll make sure that's set to yes. The last of the directives I want to show you is PasswordAuthentication. By default, it's set to yes, but is commented out with a pound sign. In order to deny users logging in with a password, leaving them only with the option to log in with keys, I would set this to no, and make sure that it's uncommented. But for now, I'll leave this as it is, because we'll use passwords to log in in this video. Later, it can be disabled if need be. Back here in the configuration file, I'll check that the port is set to 22, and then I'll look for PermitRootLogin.
Right now, it's set to prohibit-password, but I'll change that to no, and then I'll look for PubkeyAuthentication, which is just a few lines below it and make sure that that's set to yes. Then I'll look for PasswordAuthentication, and I can see that it's commented out, and that's what I expect. I'll save these changes and exit. Because I've changed the settings here, I need to restart the SSH service with sudo systemctl restart sshd.
Now I'll use another machine to connect to this one. But first, I need to know my IP address, so I'll write ip a, and I can see that this system's IP address is 10.0.1.51. Over here on my other machine, I'll make sure that the open SSH client is installed with apt install openssh-client. It's already installed. That's the client software, not the server, though you can have both installed on the same machine. I'll use the SSH software to connect to the IP address of my server. This could be a host name, too, if you have a DNS name set up for the server.
If I just leave the address by itself, SSH will try to connect using the user name that I'm using on the client machine. To make sure that I use the name of my user on the server, I'll write that here at the beginning with an at sign. The first time I connect to a remote machine, I'm asked whether I want to trust the fingerprint of the server. If I accept this, in the future, my client will check to make sure that the fingerprint is the same. If it is, I won't see any message. The fingerprint is generated when the server's installed, so if the software gets reinstalled, or if the actual computer at this address changes, it'll have a different fingerprint, and I'll be warned about that.
Now I'll type the password of my user on the remote machine. And here's the shell on the machine. If I use the who command to see which users are logged in, I can see my login here on tty2, that's my console login, and then here on pts/1 is my remote login, including the IP address from which I'm connecting. When I'm done using the remote shell, I can type exit, and the connection will be closed. The SSH client is installed by default on Linux and macOS, and the server is usually installed by default on installation patterns that are intended for servers, but it's available from the repositories, too.
Let's take a quick look at connecting to the server from Windows. In order to connect to an SSH server from Windows, we need to install client software, and a very common app for this is called PuTTY. It's available from this site, putty.org, and then click on You can download PuTTY here. From this page, you can choose the installer that you want, a 32-bit or 64-bit installer. I've downloaded that and installed it, so I'll load it from my Start menu. Here in the Host Name box, I'll type the IP address of my server, 10.0.1.51.
I'll leave the port on 22. I'll make sure SSH is selected, and then I'll press Open. Just like on my Linux machine, I'm being prompted to accept the fingerprint, so I'll press Yes, and then I'm asked for the username and the password. Now I'm connected to my Linux machine from my Windows machine. Again, when I'm done using this connection, I can type exit and the connection will be closed.
Note: Because this is an ongoing series, there is no certificate of completion available for this course.