Introduction

When I first dove into the world of Linux servers and EC2 instances on AWS, I was absolutely thrilled by the concept of SSH keys. Seriously, they are like magic keys to a secure kingdom! Unlike passwords, SSH keys are nearly impossible to crack using brute force, and when you throw in IP whitelisting through AWS security groups, you’ve got a setup that feels rock solid.

But then came the next adventure: CI/CD pipelines. I found myself asking, “How can I make sure the connection between my runner and the EC2 instance stays super safe?” As I explored this topic, a lightbulb moment hit me—I already knew the answer but just hadn’t connected the dots!

In this blog post, I am going to share my experience on what I learned about SSH keys and some of the security benefits that we get once we implement them. So, if you are interested in the details then come along for a ride.

TLDR;

If you already know about this topic and just here for the code, then don’t worry. You can directly jump to the code and setup to get what you are looking for.

What is an SSH key?

Imagine an SSH key as a special key that can unlock a secure door. In the world of servers, you need this key to gain entry. That’s the layman’s explanation. If you want to get into the technical details, check out this article:: https://winscp.net/eng/docs/ssh_keys

Why the SSH key?

So, to connect to the server one way is a password. But, there is always a possibility of guessing the password or even the possibility of using brute force methods to get the password. However, the SSH key is a much stronger security option compared to the password plus there are some other benefits like:

• An SSH key is a cryptographic key pair consisting of a public key and a private key. This complexity makes it much harder for attackers to crack compared to a password.
• When using SSH keys, no password is transmitted over the network, eliminating the risk of interception during transmission.
• By disabling password authentication on the server and requiring SSH key authentication, you reduce the attack surface and make it much more difficult for unauthorized users to gain access.
• Once configured, SSH keys allow for passwordless login, making it easier and faster for users to access the server without remembering and typing complex passwords each time.
• SSH keys can be generated and managed on a per-user basis. This allows administrators to assign unique keys to each user, and easily revoke or change access by removing or updating the corresponding key.

So, as you can see there are several advantages due to which using the SSH key is an obvious choice. And so, for my Gitlab CI/CD pipeline, I decided to use a separate SSH key which is allowed to access the server.

The HOW TO

To configure an SSH key for the Gitlab pipeline, here are the steps:

Step 1 - Create the SSH key

Generate an SSH key that you’ll use to connect to the server. Open your terminal and run the following command:

ssh-keygen -t ed25519 -C "your_email@example.com"

Follow the prompts, and it will create a key in ~/.ssh/id_ed25519 or a location you specify. You’ll end up with two files: a public key and a private key. Keep the private key safe and never share it with anyone. We’ll use the public key to authorize access to the server.

Step 2 - Create a user on your EC2 instance (opt)

You might want to create a new user and allow that user to SSH using the key you just generated. This gives you super fine-grained control over what actions this user can perform on the server. But hey, if you’re feeling adventurous or just want to keep it simple, you can totally skip this part (like I did)!

Step 3 - Authorize the key that we generated

So, we’ve got our shiny new set of keys, but now we need to let the EC2 instance know that this key is legit for accessing the server. This is where the fun part begins! We hop into the EC2 instance, navigate to ~/.ssh/authorized_keys of the user that our GitLab CI/CD runner will use, and paste the public key content into this file. This little configuration step tells the server, “Hey, when someone shows up with the matching private key, they’re good to go!” It’s like setting up a secret handshake to get exclusive access!

Step 4 - Connect to the server

With these steps in place, you’re ready to test the configuration! Head to the folder where the id_ed25519 file was created, and then use the SSH command to try connecting to the server. Just run this command:

ssh -i <key file> username@server-ip

And this should be enough for you to connect.

Step 5 - Gitlab config

Alright, let’s dive into the last step—this is where the magic happens! To let GitLab know how to connect to your server, head over to your GitLab project. Ready? Click on Settings > CI/CD > Variables.

Once you’re in that section, it’s time to add a shiny new variable! Make sure to set it as type ‘file’ and then—drumroll, please—paste in the content of your private key! This little nugget is what allows GitLab to link up with your server during the deployment stage. Trust me, it’s like giving GitLab the VIP pass to your server party! Let’s get this show on the road!

If you are a visual learner, then you can refer to my video where I show you how to set up a complete Gitlab CI/CD pipeline for a Laravel project with a Docker setup https://youtu.be/gp3VXoLBWig.

Conclusion

And there you have it! 🎉 By harnessing the power of SSH keys, you’re not just securing your connection; you’re also supercharging your workflow in GitLab CI/CD. This level of security is crucial in CI/CD pipelines, where automated deployments happen frequently. With SSH keys, you ensure that only authorized users can access your servers, minimizing the risk of unauthorized changes and potential breaches. Plus, you gain the freedom of passwordless login—talk about a win-win! So, whether you’re deploying code or managing your infrastructure, remember that SSH keys are your trusty sidekicks on this adventure. Keep exploring, keep innovating, and may your server connections always be secure! 🚀