Introduction
This post is to secure your SSH connection between systems. Instead of using password based authentication, which should not be enabled even in a dev or test environment, but rather to use your Public Key pair to safely authenticate your systems during SSH.
Setting the Stage
For the sake of this post, I am going to assume two servers, Server 1 that I will address as control node and Server 2 that I will address as host node. This procedure can be scaled.
As you are all aware, as long as you know the username and password, you can ssh from server 1 to server 2. However, passwords should be avoided at all costs, as it is very common for these to be stolen and can lead to vulnerabilities and unauthorized access. To prevent this, you can leverage SSH using Public Key Pair, meaning Server 1 is able to authenticate and connect via SSH using Private and Public Key pairs. Security can be further enhanced using passphrases as well.
Important
The most important part of this post, is the fact that the Private Key generated should never be shared anywhere.
Foundation
What is an SSH Key Pair?
- An SSH key pair is a secure access credential used in the Secure Shell (SSH) protocol.
- It relies on public key infrastructure (PKI) technology, which is the gold standard for digital identity authentication and encryption.
- The key pair consists of two related but asymmetric keys: a public key and a private key.
Public Key and Private Key:
- Public Key:
- The public key is freely shared with any SSH server you want to connect to.
- It is used for encryption.
- When you connect to a remote server, your public key is sent to the server.
- The server uses it to encrypt messages that only you can decrypt.
- For example, if Bob wants to send you a secret message, he encrypts it using your public key.
- The public key ensures confidentiality.
- Private Key:
- The private key is kept secret and known only to you.
- It is used for decryption.
- When you receive an encrypted message from the server, you use your private key to decrypt it.
- The private key remains on your local system.
- Only you can decrypt messages encrypted with your public key.
- Private-key cryptography ensures that only authorized parties can read the original message.
Deployment
- Once you’ve located a secure location for your private key, generate it using the following command (depending on your requirements and encrytption)
ssh-keygen -m PEM -t rsa -b 2048 -C vmName -f LOCATION_TO_PRIVATE_KEY
- If you are building a new VM, let’s say on Azure - then you can follow this Lab to complete the build and testing your connection to the Linux VM.
- If you are going to connect to an existing VM or host node, then the next steps is to copy the public key over to the host node. This can also be achieved through the terminal, so that it ends up in the right location.
ssh-copy-id -i LOCATION_TO_PUBLIC_KEY username@IP_OR_FQDN_HOST_NODE
- Connecting to your host node can be achieved using the following
ssh -i LOCATION_TO_PRIVATE_KEY username@IP_OR_FQDN_HOST_NODE
“Look Ma no password” :)
If you are using Windows then use Putty and Puttygen to achieve a similar outcome. Putty can be used to connect using your private key and puttygen can be used to create your Private and Public Key.
Summary
- Do not ever COPY your Private key onto a Public Repository - even if it is private !
- There are some good strategies around backing up and protecting your private key - Password managers, Vaults, Key Vaults are some of the choices.
- Set up your SSH using Key Pair - you dont need to setup passwords.