OpenSSH Basics Guide for UNIX-like Systems

Overview

This guide assumes you know the basics of using the command line! If you're unsure about how to use the command line, read my guide here.

What is SSH?

The Secure Shell protocol (SSH for short) is the solution to a security problem that was discovered in 1995, when Tatu Ylönen discovered that a password sniffer was on his university network. He then created the first version of the protocol, now known as SSH-1. SSH was made to replace Telnet and serves a similar function of communicating and controlling other machines; typically remote servers. This allows system administrators to alter and configure systems remotely, which eleminates the need to be physically connected to the machine, and thus SSH is essential for any aspiring system administrator and/or developer to know!

How Does SSH Work?

Data is broken down into several packets, and each packet contains a five elements:

The padding and payload is encrypted for every packet that is sent, making it much more secure than Telnet, which was unencrypted. But how does the authentication work?

Think of the packet(s) you're sending as a file with a padlock on it, your padlock, and only you have the key. Then you send this file to your friend, who puts his padlock on it, and then sends it back to you, and you remove your padlock and send it back. Now your friend can remove his padlock and read the file.

What is OpenSSH?

OpenSSH is the most popular SSH client and server daemon, and is used by professionals (and hobbyists like myself) every day. It was forked from Björn Grönvall's OSSH software, and was released in 1999 by the OpenBSD team. A more in-depth read on their history and the team members who participated can be found here.

"[Open Secure Shell] is the premier connectivity tool for remote login with the SSH protocol. It encrypts all traffic to eliminate eavesdropping, connection hijacking, and other attacks. In addition, OpenSSH provides a large suite of secure tunneling capabilities, several authentication methods, and sophisticated configuration options."

Quote from OpenSSH.com

Ensuring OpenSSH is Installed and Running

Most of our interaction with SSH/OpenSSH will be through the command line, so the first thing we need to do, is use a terminal to ensure that OpenSSH is installed on our client, i.e. the machine we want to connect from. Boot up your preferred terminal emulator, and run the following command:

$ ssh -V

If the command returns a line containing a version number, you have OpenSSH installed! If you get an error, look up how to install OpenSSH for your UNIX-like environment. As there are so many package managers and ways to install OpenSSH, I will not cover it here.

Once we've verified that OpenSSH is installed on your client machine, we must then ensure the same for the server, i.e. the machine we want to connect to.

Now it's time to make sure the SSH daemon (sshd) is running on the server. As I can't cover every init system, I encourage you to look up your UNIX-like environment to find out how to start/stop/check daemons. If you are on a Linux distro however and are unsure about what init system you're running, you're most likely running systemd, and here's how to check if a daemon is running using systemd:

# systemctl status sshd.service

And here's how to start it, if it isn't running:

# systemctl enable --now sshd.service

If you're not logged in as root, you need to run these commands with sudo!

Basic Usage

When we connect to a remote machine for the very first time, this could be anything from a virtual machine, another computer in our home, or an actual server that we're running/renting, we're going to get a seemingly intimidating prompt that states the authenticity of the host cannot be established. It then prints the key fingerprint for this host, and asks if we're sure we want to connect -- that's all it is, it's a confirmation prompt that asks if we really want to connect to the machine, we're trying to connect to.

Now that we know what to expect, try to use the following command to connect to a remote machine:

$ ssh username@address

ssh is how we use OpenSSH.

username is the name of the user you want to log in as. This is the user on the server, not on the client!

address is the destination of the connection, i.e. the IP address of the server.

Since this is likely the first time you're connecting to this specific machine, the scary prompt is going to appear, but just type yes and press enter to proceed with the connection. The prompt will appear every time you connect to a remote machine that is not listed in the known_hosts file, in the ~/ssh directory. Typing yes to this prompt, will add this remote machine to the known_hosts file.

Then a password prompt should appear, this is password of the user we're trying to connect as -- not the user we're currently logged in as!

SSH Keys

What are keys? Keys are encrypted files that contain a long string of characters, and they are a lot safer than passwords, as they can be much more complicated and harder to crack!

When we generate a pair of keys, we get a private key and a public key. We need to keep the private key hidden and safe from everyone else, the public key is safe to be shared, and is exactly what the server will need to have in order for us to log in without a password.

Here's how we generate a new pair of keys:

$ ssh-keygen -t ed25519 -f ~/.ssh/[filename] -C "This is a comment"

Here's what each part does:

ssh-keygen is the program we're running to generate the key pair.

-t ed25519 is the key type. ed25519 is the standard and is considered the best.

-f ~/.ssh/[filename] is the location and name of the key we are generating.

-C "This is a comment" is uite self-explanatory; it leaves a comment on the key which can help the ones who need to use the key.

I recommend using one key per remote machine, so that if one key is compromised, the others are safe.

After running the above command, we should see a two new keys, a private key: private_key_name and a public key: public_key_name.pub in the ~/.ssh directory. Notice the .pub at the end of the public key!

Transferring the Public Key to the Server

In order for us to connect to a machine that has password authentication disabled, we must first copy a public key (not a private key!) to the server you're trying to connect to. 

$ ssh-copy-id -i ~/.ssh/public_key.pub username@address

Server Configuration

For maximum security, I recommend disabling password authentication, so that we're forced to use the key pair we just generated in the previous section. To do this, edit the file /etc/ssh/ssh_config, on the server.

Find the following line and edit it from this:

#   PasswordAuthentication yes

To this:

   PasswordAuthentication no

Notice the missing number sign! Removing the number sign uncomments the line, so that OpenSSH reads that line and configures itself accordingly.

Save and close the file.

Configuration File

A config file can be created in the ~/.ssh directory, with the name config to make it easier and faster to connect to remote machines, and is essential when you're working with more than one remote machine.

Here's the basic structure of the config file: 

Host alias_to_be_used
 Hostname ip_address
 IdentityFile file_path
 User username

An example config file:

Host pi
 Hostname 192.232.5.63
 IdentityFile ~/.ssh/pi
 User piuser

Host nas
 Hostname 192.102.10.44
 IdentityFile ~/.ssh/nas
 User nasuser

Now when we want to connect to a known remote machine, all we do is use the following command:

$ ssh alias_to_be_used

Example:

$ ssh pi

Moving Files Over SSH

To move files from the local machine to the remote machine, we're going to use the scp command:

$ scp example_file username@address:/path

If you disabled password authentication, as I recommended, the above command won't work, because you need to specify a key to be used:

$ scp -i ~/.ssh/private_key_name example_file username@address:/path

The -i flag tells the command to use the specified key for authentication.

Of course, change path to your desired directory path.

To move files from the remote machine to the local machine:

$ scp username@address:/path/example_file .

Troubleshooting

Too Open Permissions

You may get a message stating that your permissions are too open, and if that's the case, run the following command:

$ chmod 600 ~/.ssh/private_key_name

Replace private_key_name with the name of your private key(s.)

You must do this for every private key!

Additional Resources

Closing Notes

Thank you for reading this blog post!

Was this useful? Perhaps.