Accessing Remote Machines Using SSH (2024)

Software developers need a way to access remote computers from their own. Why? Maybe to send some data or to execute commands. It’s a routine practice.

There are a variety of programs that give developers this functionality. Telnet is a terminal program that allows users to login to remote computers on the same network. Ftp provides a way to transfer files between computers. They have been around for a long time, but their weakness lies in the fact that they lack security.

SSH, or Secure Socket Shell, provides users with secure access to remote machines via an encrypted connection. All data sent from the client (your computer) is encrypted. Only when the data reaches the remote server will it decrypt. The process of data encryption is transparent. It happens behind the scenes and will not interrupt your workflow. This is a huge benefit. Tools like telnet and ftp don’t provide this layer of security.

One of the main advantages to using SSH are SSH keys. They are a cryptographic public/private key pair used for authentication. They always come in twos. The private key is stored on the client. The public key is stored on the remote machine.

When a user makes an attempt to connect to a remote machine via SSH, the protocol will check the user’s computer for the private key that matches the public key stored on the remote machine. If there is a match, the connection is successful. No password needed! You can even add a passphrase for added security, but we’ll touch on that later.

There are two situations that come to mind.

1. Logging in to a remote server
2. Accessing GitHub

If you are accessing a remote server for professional use, there’s a damn good chance you’re already using SSH keys. If not, read on.

If you own a private server and you’re not using SSH keys for authentication, it’s time to start thinking about it. I’ll walk you through the process.

Note: SSH is widely available on most operating systems, but the instructions below have all been executed on Mac OS.

These steps will help you set up SSH keys on your own private server. All commands will be entered through the terminal.

Step 1: Generate SSH Keys

Open the terminal on your local machine. Run the following command:

ssh-keygen -t rsa

The -t option specifies what type of key to generate. We've specified a key with the type rsa. It is just a type of key based on the RSA algorithm.

There are number of options you can add to the command above. For instance, GitHub’s documentation for generating SSH keys uses the -b option, which lets you specify how many bits in the key. Type man ssh-keygen in your terminal for more documentation.

Step 2: Name your SSH keys

After entering the command, you should get this output:

Generating public/private rsa key pair. Enter file in which to save the key(/Users/<local_user>/.ssh/id_rsa)

<local_user> refers to your local computer's current user.

The terminal instructs us to enter the name of a file in which we want our private key to be saved. You have 2 options:

1. Choose the default filename id_rsa
2. Provide your own unique filename

Two important things to note here:

• If you plan on having multiple SSH keys, it’s best to name each one uniquely.
• If you decide to provide a unique filename, you must type in the complete file path along with the filename

Personally, I append a unique word after id_rsa that describes which remote machine the key will be used to connect to. My GitHub SSH key is named id_rsa_github. The key for my personal server is id_rsa_website.

Hit Enter to choose the default id_rsa filename, or type in your own along with the file path /Users/<local_user>/.ssh/ and then hit Enter.

Step 3: Enter a passphrase (optional)

After entering the name of the file that you want to save your SSH key to you’ll get the following output:

Enter passphrase (empty for no passphrase):

What is a passphrase you ask? It’s an added layer of security on top of your SSH keys. Think of it as a password on top of a password. If you choose to go with a passphrase, you’ll be prompted to enter it every time the SSH protocol authenticates your private SSH key.

You may be thinking, “But Jake, isn’t the purpose of SSH keys to avoid typing a password every..single..time?”

Well, no. Not really. There is a benefit that you don’t have to memorize a password for every remote server you need access to. But that’s not the purpose. A passphrase just adds more security.

The downside of course is the continuous prompt to enter said passphrase. This will annoy you eventually. Trust. There are ways to disable the passphrase prompt, but I will not go over them in this post.

For the sake of this write up, let’s pass on the passphrase (no pun intended). Click Enter twice and let's move on.

You should then get some funky output telling you that your SSH keys have been saved to two files:

/Users/<local_user>/.ssh/<filename> /Users/<local_user>/.ssh/<filename>.pub

Notice that two keys have been generated. The first one is your private key, which will be stored on your local computer. The second is the public key. It should be a dead giveaway because of the .pub extension. This is the key that will be placed on the remote machine.

Step 4: Move the public key to the remote machine

The public key has to be placed on whatever remote machine you plan on accessing via SSH. On Mac it’s pretty simple to do this.

In your terminal, enter:

ssh-copy-id -i ~/.ssh/<public_key_file> <user>@<remote machine>

ssh-copy-id moves the public key file specified with -i ~/.ssh/<public_key_file> from your computer to <remote machine>. It will be stored in the file ~/.ssh/authorized_keys in the directory of <user>.

<user> should be the user you are attempting to login to <remote machine> with.

If you only have one public key file in your local ~/.ssh directory, you can omit the -i ~/.ssh/<public_key_file> option. This is really only necessary if you have multiple public keys, because ssh-copy-id needs to know which key you want to move.

After you run the command, you’ll be presented with some output that might look alarming at first glance. Don’t worry. It’s only because this is the first time you’re attempting to authenticate with the remote machine via SSH keys. Follow the terminal instructions and you’ll be all set!

Step 5: Test your connection

Go ahead and attempt to login to the remote machine using:

ssh <user>@<remote machine>

If you chose to go with a passphrase in step 3, you’ll be prompted to enter it. If not, you will notice that you’ve logged in to the remote machine without typing a password at all. Success! You’re authenticated!

I hope this quick write up proves useful to you. SSH keys are not only a secure way of logging in to remote servers, but are quite convenient. If you have any questions, feel free to reach out to me on Twitter. Happy hacking!