There are so many articles on SSH online, but when I was learning it felt like very few were beginner-friendly. My goals here are to provide you with a basic understanding of SSH, and enough information to create your SSH keys and connect to a server. I've tried to keep technical terms to a minimum and stick to the basics.

What exactly is SSH?

According to Techopedia:

Secure Shell (SSH) is a cryptographic protocol and interface for executing network services, shell services and secure network communication with a remote computer. Secure Shell enables two remotely connected users to perform network communication and other services on top of an unsecured network.

But what is it really?
Basically, SSH is a way to connect your computer to different computers or services. There are a wide range of authentication methods (source), but usually, when people talk about connecting to something via SSH, they're referring to public key authentication.

Using SSH's public key authentication is like using a username and password to log in and connect to some service, but more convenient (no need to enter your credentials every time) and secure.
For example, if you register your credentials (called SSH keys) with a remote computer, you can access that computer from yours using the terminal. When you connect, you can use the terminal as if you're using the terminal in that remote computer, and execute the same commands (like cd or ls).

So what are SSH keys, and how do they work?

What are SSH Keys?

SSH keys consist of a pair of keys, called a public and private key.
This article has the most intuitive explanation on this topic that I've seen, so I highly recommend it.

• Think of a public key as being the lock. It’s not actually a key, it’s a padlock you can make lots of copies of and distribute wherever you want. For example, if you want to put your ‘padlock’ on an ssh account on another machine, you would copy it to ‘authorized_keys’ in the ~/.ssh folder. You’ve setup the padlock.
• Think of a private key as being the actual key. This is what you use to open the padlock that is stored on the other machine. Just like a regular key you keep it secret, safe, and out of the wrong hands.

The most important takeaway here is: NEVER share your private key.
If you do, anyone can pretend to be you.

One common usage of SSH is to connect to Github. Most people probably run into this situation when they're starting out. Until you add your SSH key to Github, you have to enter your username and password each time you want to push some code. But once you add your public key (the padlock) to Github, and have your private key (the key) registered in the ssh-agent (basically a key manager that tries each of your keys one by one), you're authenticated automatically and no longer have to enter your credentials.
If you haven't done this yet, Github's guide walks you through it.

How do the keys actually work? We won't go into details here, but I think this article explains it well (the "client" is your computer and the "server" is the remote computer/service):

When a client attempts to authenticate using SSH keys, the server can test the client on whether they are in possession of the private key. If the client can prove that it owns the private key, a shell session is spawned or the requested command is executed.

Generating your keys

Computers don't come with auto-generated keys; you have to make them using a command called ssh-keygen. For details, you can refer to Github's guide that I mentioned earlier.

A few questions that come to mind regarding key generation:

• Q. Do I need to ssh-keygen a different key pair for each server/service, or can I use the same keys everywhere?
  A. You can use the same keys. Having separate keys for separate destinations doesn't make it safer from an authentication perspective. (source)

• Q. I have a multiple computers. Should I copy the keys from one device to another and share them, or generate new ones for each computer?
  A. Technically you can do either, but I recommend the latter approach, and it also seems to be the more common one (source). I have a work computer and a personal one, but they have different keys.

  • Sharing the same keys:
    • [Pro] More convenient because you only have to register one key for all your devices to access a service.
    • [Con] If one of your devices gets stolen and the key gets compromised, the keys for all your devices would be compromised.
  • Using different keys for each computer:
    • [Pros] Even if one of your devices gets stolen, you can simply delete that particular key from the list of authorized keys and your other devices would stay safe. Also, you can control which of your computers have access to what.
    • [Con] You have to manually register multiple SSH keys if you want multiple devices to be able to connect to a service.

• Q. Where are my keys stored and how can I see them?
  A. If you've used the default settings, your keys are probably saved in ~/.ssh. Try the first line of the commands below in your terminal and see if the result is a long string that starts with ssh-rsa. If so, that file, called id_rsa.pub, is your public key. Your private key should be saved in the same directory as id_rsa.
  

cat ~/.ssh/id_rsa.pub # public key
cat ~/.ssh/id_rsa # private key

How to connect to a server via SSH

Once you've generated your SSH keys, you need to copy your public key to the server(s) you want to access. This can be done with a command called ssh-copy-id, which looks like below. If you need more details, SSH's official guide covers the specifics.

ssh-copy-id -i ~/.ssh/id_rsa.pub user@server.address.com

Afterwards, if you want to access the remote server, you can do so with this command from the terminal.

ssh user@server.address.com

For example, my company has a server. Let's say it's called companyserver.com. And my username is risa. Then, the command would look like this: ssh risa@companyserver.com

If you're connecting to that server for the first time, you will most likely see a prompt like The authenticity of host 'companyserver.com' can't be established. ECDSA key fingerprint is <long string>. Are you sure you want to continue connecting (yes/no)? Enter yes to continue connecting.

The default port for SSH is 22. If you need to connect to a different port, you can do so by adding the -p option, like -p 1234.

Copy files between your computer and remote server using scp

Let me tell you about a handy command that uses SSH. You may be familiar with the terminal's cp command, which lets you copy a file inside your computer and rename it.

cp original_folder/file_name new_folder/new_file_name

scp is a similar command that lets you do this to/from a remote server. In other words, it lets you upload and download files remotely.

scp file user@server.address.com:path # upload to remote server
scp user@server.address.com:file path # download from remote server

For example, if I wanted to upload a file to my company server, it would look like this:
scp file_to_upload.txt risa@companyserver.com:
If no path is specified after the colon, the file should be uploaded to the home directory with the same name. Do remember to include the colon though!
On the flip side, if I wanted to download a file from my company server, it should look like this:
scp risa@companyserver.com:file_to_download.txt local_path

Remember, the order is always original_location then new_location.

Hopefully this post has served as a starting point for anyone learning about SSH. Thank you for reading!