How to Set Up SSH Keys

Posted on by David Singer
Reading Time: 6 minutes

This tutorial describes the process of setting up SSH Keys for use when logging in to a remote server via SSH.

File Synchronization 101: The Basics
I. Using rsync to Transfer and Synchronize Local and Remote Systems
II. How to Set up SSH Keys for Use with File Synchronization


SSH, OpenSSH, or a compatible SSH server are required for this tutorial. Windows users will want to download an SSH client like PuTTY or MobaXterm to use SSH sessions with Windows OS.

Please note, this guide will show you how to set up SSH keys in one particular method. Depending on how you use SSH, there are several other options that can be modified to meet your specific needs. For more information, search Google for “SSH Keys” and you will find many guides describing the other approaches for SSH.

This tutorial assumes that you already have a .ssh directory on the server in your user’s directory (example: /home/myuser/.ssh/). If not, use the normal user/password authentication (example: ssh to connect to a server for the first time. This should create a .ssh directory with the correct permissions. If it does not create a .ssh directory, you will need to create one;

mkdir -p $HOME/.ssh
chmod 0700 $HOME/.ssh

Step 1: Creating Your Personal Key

Open a terminal/shell on your local computer and run the following command:

user@localhost # ssh-keygen -t rsa (or)
user@localhost # ssh-keygen -t rsa -b 4096 -C "$(whoami)@$(hostname)-$(date -u +%Y-%m-%d-%H:%M:%S%z)" (for a stronger key)


You will then be asked where you would like to save the newly created key. The default setting is normally acceptable (just press enter to accept the default) but, if you are setting up a key as a local root user, you may want to store your key in a different location.

Generating public/private rsa key pair.
Enter file in which to save the key (/home/username/.ssh/id_rsa):


$HOME/.ssh/id_rsa – will contain your private key.
$HOME/.ssh/ – will contain your public key.

Next, you will be prompted to enter a passphrase. If you choose to utilize a passphrase, you will be required to type it in every time you use the key to connect to a server (spaces are ok to use; so your passphrase can be an entire sentence if increased safety is more important to you). You can choose not to use a passphrase but this is generally considered less secure.

Example: You have a laptop and are creating an SSH key to connect to your server. If you create the key without a passphrase, and your laptop is stolen, the thief could connect to your server without needing anything else. If our key has a passphrase nobody can use your key without knowing the passphrase. If you are comfortable with a little more risk, then you may choose to create your key without a passphrase.

Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/username/.ssh/id_rsa.
Your public key has been saved in /home/username/.ssh/
The key fingerprint is:
The key's randomart image is:
+---[RSA 4096]----+
|. . . .          |
| = o . .         |
|o.= . . . .      |
|oDo . . . . .    |
|B. .. Y .        |
|O+.. o . .       |
|O++.o o . . .    |
|=*. . ... . . o. |
|.o.=+.++. . .    |
root@host [~]#


Note: you can change your passphrase at any time using the command:

root@host [~]# sshkeygen -p

Step 2: Copying Your Personal Key To The Server

Before we copy your new public key to your server, we will add it to the local authorized_keys file.

root@host [~]# cd ~/.ssh
root@host [~]# cp authorized_keys

If an authorized_keys file already exists on your local machine, you will need to open and edit the file with your favorite text editor and add the key manually.

Now, we will copy your public key to the server. In a typical server, every user on the server has their own .ssh directory and their own authorized_keys file. Assuming that your user accounts are located in the /home directory, you will need to determine what user you want to log in as before you copy your public key. The root user is slightly different; In most servers, the root user’s ssh files are stored in /root/.ssh/.

Let’s say I have created a key for my local user on my laptop, but I want to use that key to connect as root using SSH. I would have to copy my new public key to the root user’s ssh directory on the server.

user@localhost [~]# cd ~/.ssh
user@localhost [~]# scp authorized_keys


Just like with your local copy, if the authorized_keys file already exists on the server you will need to add the new key to the file manually.

Caution: Depending on your version of SSH, you may get an error similar to the following when trying to log in to the server:

ssh password:
stdin: is not a tty
/root/.ssh/authorized_keys: Permission denied


If you see this, it’s most likely a permissions issue. Let’s get it taken care of right now… We’ll start by renaming the public key in .ssh/authorized_keys to .ssh/authorized_keys2 to backup the existing key:

cp -av authorized_keys{,.2}
'authorized_keys' -> 'authorized_keys.2'


Next, let’s verify the .ssh folder permissions are set to 0700:

stat /home/youruser/.ssh/
File: /home/youruser/.ssh/
Size: 4096 Blocks: 8 IO Block: 4096 directory
Device: 801h/2049d Inode: 61080373 Links: 2
Access: (0700/drwx------) Uid: ( 1000/ youruser) Gid: ( 1000/ youruser)
Access: 2019-08-21 09:40:09.599161015 -0400
Modify: 2019-08-21 09:40:07.363167537 -0400
Change: 2019-08-21 09:40:07.363167537 -0400

(If the .ssh folder permissions are something other than 0700, use the command “chmod 0700 /home/youruser/.ssh/” to modify it)


Next, we will view and if needed, modify the permissions of the .ssh/authorized_keys file to 640

cd .ssh/
user@localhost:~/.ssh$ stat authorized_keys.2
File: authorized_keys.2
Size: 768 Blocks: 8 IO Block: 4096 regular file
Device: 801h/2049d Inode: 61100030 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 1000/ user) Gid: ( 1000/ user)
Access: 2019-08-21 09:37:24.579636710 -0400
Modify: 2019-08-21 09:19:43.818521613 -0400
Change: 2019-08-21 09:39:56.987197777 -0400


Whoops! 644. Let’s change those permissions to 640

user@localhost:~/.ssh$ chmod 640 authorized_keys.2


Now, stat the file to re-check its permissions

user@localhost:~/.ssh$ stat authorized_keys.2
File: authorized_keys.2
Size: 768 Blocks: 8 IO Block: 4096 regular file
Device: 801h/2049d Inode: 61100030 Links: 1
Access: (0640/-rw-r-----) Uid: ( 1000/ user) Gid: ( 1000/ user)
Access: 2019-08-21 09:37:24.579636710 -0400
Modify: 2019-08-21 09:19:43.818521613 -0400
Change: 2019-08-21 09:43:49.546511500 -0400


Perfect!. Now, let’s move the updated file back to its original name:

user@localhost:~/.ssh$ mv authorized_keys.2 authorized_keys


Next, let’s copy that updated key over to the server: (use your user login info in the bolded text)

user@localhost:~/.ssh$ scp /home/user/.ssh/authorized_keys root@serverIP:/root/.ssh/
root@serverIP's password:
stdin: is not a tty
authorized_keys 100% 768 737.6KB/s 00:00

Step 3: Logging In With Your New Key

Now that your new key has been copied to the server, you can start using it for SSH logins. If your username is the same on your local machine and on your server, you can connect simply with:

Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '[] (ECDSA) to the list of known hosts.
Last login: Wed Aug 21 09:13:32 2019 from


If your local username and the username you log into the server with are different, you can specify the user you would like to log into the server as using this command:



In the previous example, I copied my key so that I could log in to my server as root. Now that the key is in place on the server, running the command:

will result in different behavior. If you chose to use a passphrase with your key, you will be asked for your passphrase and then you will be logged in to the server. If you did not use a passphrase you will immediately be logged in to the server after you enter the ssh command.

Congratulations! You have successfully set up an SSH key.

Step 4: More Advanced Configurations

Passphrase-less Logins While Still Having a Passphrase
Earlier in this article, we covered passphrases and some advantages and disadvantages of using them in your key. It is possible to use your key in a way that you are not prompted to type it in your passphrase every time you connect to a remote server.

Your key can be loaded into the memory of your local computer, so you will only have to type in your passphrase one time and every subsequent ssh session will automatically attempt to log in.

On your local computer terminal/shell, type in the command ssh-add. You will be prompted for your passphrase and after that, you should receive a confirmation that the identity has been added.

Now you can use your key several times without having to type in your passphrase every time.

Specifying Usernames for Hosts
In your .ssh directory on your local computer, you can also specify what username you want to use with different servers by creating a config file.

Here is an example of a simple config file entry for specifying a username:

Host *
User root

This entry would cause ssh to always use the user root when connecting to the server, or any subdomain of

If you still have questions about setting up or connecting using an SSH key?
Our Support Team can assist with this or other issues you may be experiencing with SSH Keys. If you are uncomfortable walking through the steps outlined here, give us a call at 1.800.580.4985, or open a chat or ticket with us.

Avatar for David Singer

About the Author: David Singer

I am a g33k, Linux blogger, developer, student, and former Tech Writer for My passion for all things tech drives my hunt for all the coolz. I often need a vacation after I get back from vacation....

Latest Articles

Controlling PHP settings with a custom php.ini file

Read Article

How to install Puppet Server on Linux (AlmaLinux)

Read Article

Email security best practices for using SPF, DKIM, and DMARC

Read Article

Linux dos2unix command syntax — removing hidden Windows characters from files

Read Article

Change cPanel password from WebHost Manager (WHM)

Read Article