SSH Key Pair Authentication Setup

Ever wanted to connect to a remote server or host and tired of typing a password and worrying about password attacks. The solution is to use SSH key pairs, we will be covering SSH key pair authentication setup.

In addition, passwords shouldn’t be used in today production environments as they are typically weak in comparison with a public and private key pair. Multi-factor authentication should also be used, however this post will not be covering this setup.

SSH Key Pair Generation

To generate these keys, you will use ssh-keygen. Do not use RSA or DSA, they are weak, the strongest encryption key out at the moment is ed25519.

Use command:

ssh-keygen -a <large integer value> -t ed25519 -f ~/.ssh/id_ed25519 -C "<Username/Comment>"

For Example:

ssh-keygen -a 10000 -t ed25519 -f ~/.ssh/id_ed25519 -C “Nate15329”

If you use a long and strong passphrase, this will avoid from someone using these keys if they ever got a copy. You will need to type in the passphrase like a password when remoting in, but also the SSH key is also validated.

Remote System Setup

Next is preparing and copying the public key to the remote system that is being accessed. Never copy the private key to another system. Public keys end with .pub extension and only these are to be copied to remote systems.

Ensure the remote system has the following folder structure and file preexisting for the account. Below are the commands to get these setup.

mkdir ~/.ssh
touch ~/.ssh/authorized_keys
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Copy the key to remote system via:

ssh-copy-id <user>@<server name/ip address>

or from Windows Powershell to new remote system:

scp $env:Userprofile\.ssh\id_ed25519.pub <user>@<server name/ip address>:~/.ssh/authorized_keys

or from Windows PowerShell to remote system with existing ssh authorized keys:

type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh <user>@<server name/ip address> "cat >> .ssh/authorized_keys"

Remote System SSH Lockdown

To prevent SSH daemon from using passwords as a secondary authentication method, please do the following.

  1. Open /etc/ssh/sshd_config with your favorite file editor as sudo or root user.
    • Note: We do not endorse the usage of logging in as root as mistakes may happen and things will break, along with a high security risk.
  2. Find PasswordAuthentication and set it to no (PasswordAuthentication no)
  3. Find ChallengeResponseAuthentication and set it to no (ChallengeResponse Authentication no)
  4. Save and close the file.
  5. Restart your sshd daemon, usually by sudo service sshd restart or sudo systemctl reload sshd

Congrats, now your system should only accept SSH key authentication.

Log2RAM – SD Card Savior

While setting up our Raspberry Pis, one of the things that we usually setup is Log2Ram. The entire goal of this project is to extend the SD storage life.

By default Raspberry Pi stores logs on the SD card, however SD cards have limited write cycles due to being FLASH based storage. Once this limit has been reached, it will fail. Log2Ram forces logs to be stored in memory (RAM) by changing /var/log to a RAM disk and once every day to reduce writing and increase lifespan of the SD card.

Highly recommend for any environment running off of an SD card, along with configuration and sending logs to a central logging system such as syslog. We won’t be covering the central logging, but recommended for production environments.

Installation is pretty straight forward.

git clone https://github.com/azlux/log2ram.git
cd log2ram
chmod +x install.sh
sudo ./install.sh

Usually I edit /etc/log2ram.conf to set size to 128 MB instead of default 40MB by using sudo nano /etc/log2ram.conf

SIZE=128MB

Then a restart would be need to be done to make this become in effect by sudo reboot

With future updates, I suggest following the advice that is in the README file. Usually, we would need to manually stop the service prior to running the update.