Encryption 101: How to SSH using Private Key on Debian Linux (Step-by-Step Guide)

By Amanda D | Last Upload on Feb 2nd 2023 | Home → Tutorials → Encryption 101: How to SSH with Private Keys

---

Introduction to Private Encryption

And it’s not just businesses that need to worry about data protection. We all have a responsibility to protect the personal data of others. This includes protecting the information we store on our computers, on our smartphones and in the cloud. And it also extends to the way we send information over the Internet, either through email or by using applications that sync data between devices.

The good news is that there are a number of ways to protect data. The most common and effective method is to encrypt it.

How to Connect Over SSH using a .pem file to Server

Use the -i option:

ssh -i mykey.pem [email protected]

As noted in this stack overflow answer, this file needs to have the correct permissions set.

The SSH man says:

SSH will simply ignore a private key file if it is accessible by others.

You can change the permissions with this command:

chmod go= mykey.pem

That is set permissions for groups and others equal to the empty list of permissions.

You need your SSH public key and you will need your private key. Keys can be generated with ssh-keygen. The private key must be kept on Server 1 and the public key must be stored on Server 2.

Its keys are a way to protect sensitive data. Many devices and applications now have encryption to make it easier for people to protect their data. IT security is getting better because cryptography (a way to protect data) is becoming more common.

This is completely described in the manpage of OpenSSH so that I will quote a lot of it. You should read the section ‘Authentication’. Also, the openSSH manual should be really helpful: http://www.openssh.org/manual.html

Please be careful with ssh because this affects the security of your server.

From man ssh:

 ~/.ssh/identity
 ~/.ssh/id_dsa
 ~/.ssh/id_rsa
     Contains the private key for authentication.  These files contain
     sensitive data and should be readable by the user but not acces-
     sible by others (read/write/execute).  ssh will simply ignore a
     private key file if it is accessible by others.  It is possible
     to specify a passphrase when generating the key which will be
     used to encrypt the sensitive part of this file using 3DES.

 ~/.ssh/identity.pub
 ~/.ssh/id_dsa.pub
 ~/.ssh/id_rsa.pub
     Contains the public key for authentication.  These files are not
     sensitive and can (but need not) be readable by anyone.

This means you can store your private key in your home directory in it. Another possibility is to tell ssh via the -i parameter switch to use a special identity file. Also from man ssh:

 -i identity_file
     Selects a file from which the identity (private key) for RSA or
     DSA authentication is read.  The default is ~/.ssh/identity for
     protocol version 1, and ~/.ssh/id_rsa and ~/.ssh/id_dsa for pro-
     tocol version 2.  Identity files may also be specified on a per-
     host basis in the configuration file.  It is possible to have
     multiple -i options (and multiple identities specified in config-
     uration files).

This is for the private key. Now you need to introduce your public key on Server 2. Again a quote from man ssh:

  ~/.ssh/authorized_keys
         Lists the public keys (RSA/DSA) that can be used for logging in
         as this user.  The format of this file is described in the
         sshd(8) manual page.  This file is not highly sensitive, but the
         recommended permissions are read/write for the user, and not
         accessible by others.

The easiest way to achive that is to copy the file to Server 2 and append it to the authorized_keys file:

scp -p your_pub_key.pub user@host:
ssh user@host
host$ cat id_dsa.pub >> ~/.ssh/authorized_keys

Authorization via public key must be allowed for the ssh daemon, see man ssh_config. Usually, this can be done by adding the following statement to the config file:

PubkeyAuthentication yes

Authentication. \

This guide will walk you through creating and initiating connections using public/private keys. Using public-key authentication removes the need to enter a password every time you need to connect to a remote SSH host.

Step 1: Install OpenSSH

To create public and private keys, we need to install the OpenSSH package. Use the default package manager.

For Debian/Ubuntu:

$ sudo apt-get install OpenSSH-client -y

For Arch/Manjaro:

On an Arch-based distribution, use the command:

$ sudo pacman -S openssh

On REHL or CentOS:

$ sudo yum install openssh-client

Step 2: Generate SSH keys

With the OpenSSH packages installed, we can create public/private key pairs to authenticate SSH connections. To generate a new key pair on your Linux machine, use the ssh-keygen command. This command will overwrite your old key pair and provision a new one.

You can use the following command to generate a new key

$ ssh-keygen -t rsa -b 4096

The command will prompt you for a file name. By default, the ssh key pairs are stored as id_rsa and id_rsa.pub for private key and public key, respectively.

$ Enter file in which to save the key (/home/ubuntu/.ssh/id_rsa):

To use the default filename, press ENTER and proceed.

In the next part, enter a passphrase to secure your key pairs. You can skip this by pressing ENTER.

$ Enter passphrase (empty for no passphrase):

$ Enter same passphrase again:

Executing this will complete your SSH key pair creation, and you can use it to log in to SSH.

Step 3: Copy Publick Key to Remote Host

We can use our SSH key pair to manage remote servers by copying the public key to the server. OpenSSH provides us with a command to do this, called ssh-copy-id.

Use the command:

$ ssh-copy-id remote_user@remote_ip

The command will prompt you to enter the SSH password. Once authenticated, the command appends the public key to the ~/.ssh/authorized_keys file.

Step 4: SSH using your Private Key

After completing the process, you should log in to the remote server using an SSH private key. This means that you will not be prompted for a password.

Use the command as:

$ ssh remote_user@remote_ip

And with that, you have successfully used SSH key-based authentication. You can add an extra layer of security by disabling password logins.

Public SSH Key Management

Encryption can provide powerful security for your company, but it is essential to manage it correctly. If you get encryption wrong, either from a technology or management perspective, you could end up with scrambled data that is useless. This could be like having a corporate document shredder that doesn’t work. The trouble with encryption is often caused by weak key management. SSH uses encryption keys to protect data in transit, and these encryption keys must be managed carefully to maintain security. In this guide, we will discuss some best practices for key management with SSH.

Private SSH Key Management

One of the most important aspects of key management is ensuring that only authorized users have access to rouble with encryption is often caused by weak key management. SSH uses encryption keys to protect data in transit, and these encryption keys must be managed carefully to maintain security. In this guide, we will discuss some best practices for key management with SSH.

The Techbooks tutorial team has gone through the process of generating SSH key pairs and moving the keys to other machines. You may authenticate SSH sessions without a password by using the techniques described above. A single key pair can be used to manage many servers at once, as long as they all have the same fingerprint.