How to Connect SSH Server Using SSH Key

Here's a guide to connecting an ssh server using the ssh key

1.  Generating SSH Keys

The first step to configuring SSH key authentication to your server is to create an SSH key on your local computer.

To do this, we can use a specialized utility called ssh-keygen, which comes with the standard OpenSSH tool suite. By default, it will generate a 3072 bit RSA key.

On your local computer, create an SSH key pair by typing :


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

You will then be prompted to choose a location for the key to be created. By default, the key will be stored in the ~/.ssh directory inside your user's home directory. The private key will be called id_rsa and the corresponding public key will be called

Usually, it's best to stick with the default location at this stage. Do allow SSH You will automatically find your SSH key when trying to authenticate. If you want to choose a non-standard path, type it now, otherwise, press ENTER to accept the default.

If you have previously created an SSH key pair, you may see a prompt like this:

/home/username/.ssh/id_rsa already exists.  Overwrite (y/n)?

If you choose to overwrite the key on disk, you will not be able to authenticate using the previous key again. Be careful when choosing, as this is a destructive process that cannot be undone.

Created directory '/home/username/.ssh'. Enter passphrase (empty for no passphrase):  Enter same passphrase again:

Next, you will be asked to enter the password for the key. This is an optional password that can be used to encrypt the private key file on disk.

Since private keys are never exposed to the network and are protected through file permissions, this file should not be accessible to anyone other than you (and the root user).

Password as an optional extra. If you enter one, you must provide it every time you use this key (unless you are running SSH agent software that stores decrypted keys). We recommend using a password, but if you don't want to set a password, you can press ENTER to skip this request.

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: SHA256:CAjsV9M/tt5skazroTc1ZRGCBz+kGtYUIPhRvvZJYBs username@hostname The key's randomart image is: +---[RSA 3072]----+ |o ..oo.++o .. | | o o +o.o.+... | |. . + oE.o.o . | | . . oo.B+ .o | | . .=S.+ + | | . o..* | | .+= o | | .=.+ | | .oo+ |  +----[SHA256]-----+

You now have a public and private key that you can use to authenticate. The next step is to place the public key on your server so that you can use SSH key authentication to log in.

2. Copying SSH Public Key to Your Server

There are several ways to upload your public key to a remote SSH server. The method you use depends largely on the tools you have and the details of your current configuration.

The following methods all produce the same end result. The simplest and most automated methods are explained first, and each requires an additional manual step. You should follow these only if you cannot use the previous methods.

Copy your Public Key Using: ssh-copy-id

The easiest way to copy your public key to an existing server is to use a utility called ssh-copy-id Due to its simplicity, this method is recommended when available.

ssh-copy-id This tool is included in the OpenSSH package in many distributions, so you may already have it on your local system. For this method to work, you must currently have password-based SSH access to your server.

To use this utility, you need to specify the remote host you want to connect to, and the user account to which you have password-based SSH access. This is the account to which your public SSH key will be copied.

The command is:

ssh-copy-id username@remote_host 

The following message will appear:

The authenticity of host ' (' can't be established. ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe.  Are you sure you want to continue connecting (yes/no)? yes

This means that your local computer does not recognize the remote host. This will happen the first time you connect to a new host. Type YES and press ENTER to continue.

Next, the utility will scan your local account for the key we created earlier. When it finds the key, it will ask you to enter the password of the remote user account:

/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed /usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys username@'s password:

Type the password (your typing will not be displayed for security purposes) and press ENTER. The utility will connect to the remote account using the password you provided. It will then copy the contents of your ~/.ssh/ key to a file in the remote account's ~/.ssh home directory called authorized_keys.

Then it will appear as follows:

Number of key(s) added: 1 Now try logging into the machine, with: "ssh 'username@'"  and check to make sure that only the key(s) you wanted were added.

At this point, your key has been uploaded to the remote account. You can proceed to the next section.

Copying Your Public Key Using SSH

If you don't have ssh-copy-id, but you have password-based SSH access to an account on your server, you can upload the key using conventional SSH methods.

We can do so by outputting the contents of our public SSH key on our local computer and channeling it through an SSH connection to the remote server. On the other hand, we can ensure that the ~/.ssh directory exists under the account we are using and then output the content we are channeling into a file called authorized_keys within this directory.

We will use the >> redirect symbol to add content to override it. This allows us to add keys without breaking previously added keys.

The full command will look like this:

cat ~/.ssh/ | ssh username@remote_host "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys

You may see a message like this:

The authenticity of host ' (' can't be established. ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe.  Are you sure you want to continue connecting (yes/no)? yes

This means that your local computer does not recognize the remote host. This will happen the first time you connect to a new host. Type yes and press ENTER to continue.

After that, you will be asked for the password of the account you are trying to connect to:

username@'s password:

After entering your password, the contents of your key will be copied to the end of the otor_keys file of the remote user account. Proceed to the next section if this works.

Copying Your Public Key Manually

If you do not have password-based SSH access to your server, you will have to perform the above process manually.

The contents of your file should be appended to the file in ~/.ssh/authorized_keys on your remote machine.

To display the contents of your key, type this into your local computer:

cat ~/.ssh/

You will see the key content, which may look like this:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCqql6MzstZYh1TmWWv11q5O3pISj2ZFl9HgH1JLknLLx44+tXfJ7mIrKNxOOwxIxvcBF8PXSYvobFYEZjGIVCEAjrUzLiIxbyCoxVyle7Q+bqgZ8SeeM8wzytsY+dVGcBxF6N4JS+zVk5eMcV385gG3Y6ON3EG112n6d+SMXY0OEBIcO6x+PnUSGHrSgpBgX7Ks1r7xqFa7heJLLt2wWwkARptX7udSq05paBhcpB0pHtA1Rfz3K2B+ZVIpSDfki9UVKzT8JUmwW6NNzSgxUfQHGwnW7kj4jp4AT0VZk3ADw497M2G/12N0PPB5CnhHf7ovgy6nL1ikrygTKRFmNZISvAcywB9GVqNAVE+ZHDSCuURNsAInVzgYo9xgJDW8wUw2o8U77+xiFxgI5QSZX3Iq7YLMgeksaO4rBJEa54k8m5wEiEE1nUhLuJ0X/vh2xPff6SQ1BL/zkOhvJCACK6Vb15mDOeCSq54Cr7kvS46itMosi/uS66+PujOO+xt/2FWYepz6ZlN70bRly57Q06J+ZJoc9FfBCbCyYH7U/ASsmY095ywPsBo1XQ9PqhnN1/YOorJ068foQDNVpm146mUpILVxmq41Cj55YKHEazXGsdBIbXWhcrRf4G2fJLRcGUr9q8/lERo9oxRm5JFX6TCmj6kmiFqv+Ow9gI0x8GvaQ== username@hostname

Access your remote host using any method available. This may be a web-based console provided by your infrastructure provider.

Once you have access to your account on the remote server, you should make sure the ~/.ssh directory has been created. This command will create the directory if necessary, or do nothing if it already exists:

mkdir -p ~/.ssh

Now, you can create or modify the authorized_keys file within this directory. You can append the contents of the file to the end of the authorized_keys file, creating it if necessary, using this:

echo public_key_string >> ~/.ssh/authorized_keys

In the above command, replace public_key_string with the output of the cat ~/.ssh/ command that you run on your local system. It should start with ssh-rsa AAAA. or similar.

If this works, you can proceed to test your new key-based SSH authentication.

3. Authenticating to Your Server Using SSH Keys

If you have successfully completed any of the above procedures, you should be able to log in to the remote host without a remote account password.

The process is largely the same:

ssh username@remote_host

If this is your first time connecting to this host (if you used the last method above), it will appear as follows:

The authenticity of host ' (' can't be established. ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe.  Are you sure you want to continue connecting (yes/no)? yes

This means your local computer does not recognize the remote host. Type yes and press ENTER to continue.

If you did not provide a password for your private key, you will be logged in immediately. If you provided the password for the private key when generating the key, you will be prompted to enter it now. After that, a new shell session will be created for you with an account on the remote system.

If successful, proceed to find out how to lock the server.

4. Disabling Password Authentication on Your Server

If you can log into your account using SSH without a password, you have successfully configured SSH key-based authentication to your account. However, your password-based authentication mechanism is still active, meaning your server is still exposed to brute force attacks.

Before completing the steps in this section, make sure you have SSH key-based authentication configured for the root account on this server, or preferably, you have SSH key-based authentication configured for an account on this server with sudo access. This step will lock out password-based logins, so it's important to ensure that you can still gain administrative access.

Once the above conditions are correct, log in to your remote server with an SSH key, either as root or with an account with sudo. Open the SSH daemon configuration file:

sudo nano /etc/ssh/sshd_config

Inside the file, look for a directive called PasswordAuthentication. This may be commented out. Uncomment the line by removing the # at the beginning of the line, and set the value to no. This will disable your ability to log in via SSH using the account password:

PasswordAuthentication no

Save and close the file when you are done. To actually implement the changes we just made, you'll need to restart the service.

On most Linux distributions, you can issue the following command to do so:

sudo systemctl restart ssh

After completing this step, you have successfully transitioned your SSH daemon to only respond to SSH keys.

Did you find it helpful? Yes No

Send feedback
Sorry we couldn't be helpful. Help us improve this article with your feedback.