Setting Up SSH Server on Ubuntu Mate (Raspberry Pi 3)


A while back I purchased a new Raspberry Pi 3 to tinker with during the summer. It was my first foray into the world of Single Board computers, and I have not been disappointed! The RPi3 has a surprising amount of power, and the built-in WiFi adapter and Bluetooth are nice features!

After looking around at several of the different OS’s available, and testing Raspian for a while, I settled on the Ubuntu Mate RPi distro. For my first couple of projects, I felt like this was a good place to start.

One of the first things that I did was to set up an SSH server on the Pi in order to access it remotely, rather than having to plug in a mouse, keyboard, and a monitor. It was simple, straightforward, and quick to get configured, but I referenced several tutorials to do it. So, here’s a the combination of the different walk-throughs on how to get it up and running.

Raspberry Pi Logo


The majority of the following code snippets are to by typed directly into the server/RPi/client where you are setting up the SSH server. If otherwise, it will be stated explicitly, and the code snippets for those “local” commands will be bash commands. If you’re using a Windows device, you’ll need to look up the corresponding commands.

Also, as usual, just make sure you look out for any placeholders in the code snippets, usually denoted by being in ITALICIZED ALL CAPS.

Install OpenSSH (If Not Already Installed)

When I installed Ubuntu Mate, it came with OpenSSH installed already. In case whatever OS you’re using doesn’t come preloaded with OpenSSH, you can install it via this command (or some variation of it based on your distro):

sudo apt-get install openssh-server

Copy SSH Config File for Emergency Backup

Now that OpenSSH is installed on your machine, you’re ready to start configuring the server. But, before you start making changes to the sshd_config file (the OpenSSH Server configuration file), it would be wise to make a copy of it in case you (or someone else) messes something up. To do that, simply run the following:

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config_backup

Once that’s complete, it’s time to start configuring your OpenSSH server! Go ahead and open up the sshd_config file using your favorite editor.The majority of the rest of this tutorial involves working in and changing this file. Here’s an example of opening it up in vi:

sudo vi /etc/ssh/sshd_config

Enable Public Key Authentication

Public Key Authentication is the magic that allows SSH to work. In a nutshell, some really cool math makes it possible so that you have a secret/private key (a file filled with a bunch of text) on your machine that matches up with a public key (a different file filled with a bunch of text) on a server which allows you to authenticate without needing a username or password. There are a bunch of great posts out there about how Public-Private key encryption works, and I’ve copied several of them under the Further Readings section of this post. If you’re interested in learning more, check ’em out!

Depending on the version of OpenSSH that you have installed, this feature may or may not be enabled by default. Scan the sshd_config file for the following line and either uncomment it (remove the # from the beginning of the line), add the line, or change it so that it looks like this:

PubkeyAuthentication yes

Now that public key authentication is turned on, you’ll need to upload your public key to the server to be able to authenticate. But, let’s configure some more security settings first.

Make Security-Based Configuration Changes

OpenSSH server can become an easy target for malicious intruders. If not properly configured, it will be an open gateway into your local network, which, depending on where your server/RPi/client is, could mean that someone could have unauthorized access to personal, private information.

To mitigate this risk, here are a couple of things that you can do to harden (beef-up) your OpenSSH installation.

Disclaimer: I am not a security professional. Also, there is no such thing as “perfect security” (related video). So, even though you take the following steps, you can still be or become vulnerable to outside attacks. Take it upon yourself to do some extra reading in order to lock down your local network. I’ve included a couple of links in the Further Readings section on hardening your local/home network, and securing your SSH server.

Disable Root Login Via Password

When you login to a server via SSH, you generally connect to the remote machine through a username. For example:


This command would attempt to log me in via the user john.

As mentioned previously, SSH allows you to access a remote machine through the internet without needing a username and password. Some situations, however, call for the ability to log into a server via a username and password in case the connecting user doesn’t have a public-private key pair stored correctly.

Now, combine both of those facts with the knowledge that the root user is allowed to do pretty much ANYTHING on a machine, and you’ve got yourself into a bit of a pickle. If your OpenSSH server allows someone to try to connect to the root user via SSH, AND allows that person to attempt to login via a password, then attackers can attempt to brute-force your root password and gain unfettered access to your machine.

To combat this weakness, the people behind OpenSSH have a setting that enables/disables the ability to login to the root user via a password. Recently, they have made it so that this is NOT allowed by default (yay security!). However, just in case, here’s the line that you need to change/confirm in your sshd_config file:

PermitRootLogin prohibit-password

Make sure that the line looks like this, and that it’s not commented out, and you’re good.

Explicitly Declare with OS Users Can be Accessed Via SSH

As mentioned previously, when you login to a machine via SSH, you do so via operating system users, or user accounts on the remote machine. One nice security feature that you can add to your OpenSSH installation is the restriction of accounts that can be accessed via SSH.

For example, if you know that you only want the user john to be accessible via SSH, you can limit OpenSSH to only accept attempted connections to that user. All requests to connect to other users (root included) will be rejected.

To do this, add/uncomment (depending on your version of OpenSSH) the following line, and follow the pattern to add whichever user accounts you want to be accessible via SSH:

AllowUsers USER1 USER2 USER3... 

Note: The users are NOT  comma-separated, they are only separated with a space, and you can add as many users as you’d like here, including only a single user.

Some of the extra articles listed under the Hardening OpenSSH Server portion of the Further Readings section talk about other ways to accomplish this same task. They’re worth checking out to see if your use case would benefit from a different approach.

Change Which Port SSH Listens To

SSH, by default, listens on port 22. One added security measure is to change the default port for SSH to a different port that you choose at random.

Disclaimer: There’s a great article (check it out in the Further Readings section) that talks about why this isn’t necessarily a good idea. Though I don’t agree with all of the author’s arguments, and I do feel that this is a valid security measure, I absolutely agree with his main point: Security through obscurity isn’t enough. You can’t just hope that attackers won’t stumble onto your SSH port. Your system needs to be hardened in other areas as well.

Anyway, to change the default port, find this line in the sshd_config file and substitute the ###’s for whatever port number you’d like (make sure you don’t use a reserved/well-known port!).

Port ###

Add Public Keys to Remote Server

Now that we have some security configurations in place, save that file, and exit the text editor. Let’s move on to uploading your SSH key from your local machine to the remote machine (i.e., the machine that you just finished configuring).

Create Key-Pair (If You Don’t Already Have One)

If you don’t have an SSH key-pair already on your computer, the first thing that you’ll need to do is generate a key-pair and store the private key. This can be accomplished via the following bash command (into your local machine; i.e., the machine that you’ll be connecting from):

ssh-keygen -t rsa

This makes use of the RSA algorithm to create the public-private key pair. You’ll be prompted for several pieces of information, including where to store the key. You can just press Enter through all of the prompts without entering any information until you finally see something like the screenshot on the right in your terminal.

SSH Key Created Successfully

There are a couple of things to note here in this screenshot:

  1. You don’t have to input anything when prompted for the file or passphrase
  2. If left to default, your Private Key (identification) will be stored in the ~/.ssh/id_rsa file
  3. If left to default, your Public Key will be stored in ~/.ssh/

Make sure you note where those files are located, and DO NOT ACCIDENTALLY GIVE OUT YOUR PRIVATE KEY TO ANYONE!

Upload Public Key to Server

Uploading your SSH key to a server is super simple with a handy tool called ssh-copy-id. At the time of this writing, there’s a Mac and Linux port for this tool, but no Windows port. But, I’ll include the command to do the same thing if you choose not to, or can’t use ssh-copy-id.

If you’re on a Mac, ssh-copy-id doesn’t come preinstalled with your command-line tools. To install it, you’ll need Homebrew. If you don’t have Homebrew installed, run this command:

/usr/bin/ruby -e "$(curl -fsSL"

With Homebrew installed, run the following command in your terminal:

brew install ssh-copy-id

Note: Some Linux distros have ssh-copy-id installed by default. If yours doesn’t, then Google around to find the corresponding package.

With ssh-copy-id installed, run the following to copy your public key to the server:

ssh-copy-id "USER@REMOTE_HOST -p NEW_PORT"

Remember to substitute your username, URL/IP Address, and the newly-configured port (if you chose to change that) in this command.

If you don’t have ssh-copy-id, then the following command will accomplish the same thing:

cat ~/.ssh/ | ssh USER@REMOTE_HOST "mkdir -p ~/.ssh && cat >>  ~/.ssh/authorized_keys"

At this point, whether through ssh-copy-id or through the simple SSH command, you should now have your public key on the server!

Test It Out

The final step is to test out the SSH connection! If you designated a port other than 22 in your sshd_config file, then you can connect via the following command:


If you didn’t change it from port 22, then leave off the -p flag, and the port number, and you’re all set!

2018-03-12T02:23:45+00:00 May 17th, 2016|