Security + DevOp's Play Ground Automation Setup
Automation may be a good thing, but don’t forget that it began with Frankenstein. - Anonymous
- Playground gadgets
- Why shell script ??
- Setup Scripts
- Secrets🙊, how do you handle them?
- SSH Keys
Problem statement; I used to use a virtual environment as my playground to break and tinker around with stuff, then I got a new laptop, and I had to set up the whole environment from zero to my virtual environment state. I did it the first time manually, and when I was done setting up everything, I found out that the new laptop’s hard disk was faulty 🤬. I had to replace the hard disk and re-do the setup again.
It was tiresome, and it took me a whole week because each time I was faced with a problem, I had to fix, format the disk, reinstall the OS, and re-do the setup.
I got tired of that cycle, and I decided to google around for a solution. I came by a post by Victoria Drake, which made me realize that I can automate my setup process and simplify my life.
I want to start by noting down my
playground gadgets and then explain why I decided to use the bash shell script and not the other fancy stuff (like Vagrant, puppet, chef, or ansible).
I have four major gadgets that I use on a typical day, which are;
Tmux- handles all my terminal sessions and screens.
Vim- this is my Integrated Development Environment.
Keepass2- holds all my SSH keys and stores some of my passwords.
bash- preferred shell; this is where I call home. (I defaulted to using bash instead of ZSH)
Why shell script ??
I decided to use shell script because it will allow me to understand the language better and fine-tune my coding skills. Plus, it comes by default in most Unix systems. While with the other fancy tools, I would be forced to install and maybe configure.
Most of the gadgets mentioned above have configuration files that are called
dotfiles. I won’t explain each dotfile; check out Victoria’s post she has done most of the explanation, but I will try my best not to skip the most important bits.
The dotfiles structure; I decided to place all my dotfiles in one directory, then each config in its directory with its name.
The image above represents how I have arranged my config files. Before you ask why? Let me mention that I am a neat freak (kind of). My mind is as organized as a shelf, so that’s why!! Now you can judge me, but it works for me!
.bashfolder, I have two aliases, one containing the regular aliases and the other containing aliases with secrets, tokens, and IPs.
vimfolder contains the
YouCompleteMevim plugin config I stole from Jonas Devlieghere and the vim config file.
eddiefolder contains a
greetings.txtfile which contains lines I would like the eddie-terminal to tell me each time I spawn my terminal. Awesome right!! The project is by the one and only Victoria Drake.
The last folder was for Oh-My-ZSH, which I currently don’t use in my setup. But it contained various files that were from the bash folder but for the Oh-My-ZSH shell.
For the setup scripts, I will explain the significant bits. And for the rest, you can check out the whole project repo on my Github.
- dotfiles.sh setups all my dotfiles. Plus, it does more, so you should have a look at it.
- desktop.sh setups up my folders and desktop environment look and feel, including setting up a screensaver, background image, user profile icon, and favorite apps on my dock (
kindly read Victoria Drake's post, she explained how to do it). I want to mention that some settings like renaming the trash on the desktop don’t work in Ubuntu 19 but work with ubuntu 18. You can play around with it.
- software.sh installs all the packages I use daily and the dependencies required to install all the applications.
- setup.sh brings all the scripts together. Everything is executed from here, plus it does some cleanup, installs vim and tmux plugins,
changes my default shell from bash to zsh, and then logs out the desktop for some settings to take effect.
- sync.sh syncs all my dotfiles from the home user directory to the local Github repository so that I can update the remote repository.
Secrets🙊, how do you handle them?
The fun part; In Victoria’s post, she pointed out there were some files that one wouldn’t put on a public repo as a
best security practice. That was a problem for me because I wanted to back up everything while sharing what was required. Github doesn’t allow one to set some directories in a repository as private, so I had to think of a solution to my problem.
Later on, I found a few solutions to achieve this. I decided to stick with git-secret, which was among the solutions. It uses GPG RSA key pair to encrypt all of your desired secret files and allows you to push them to a public repository, which you can later decrypt in your local environment using the same GPG key.
I am paranoid while at the same time lazy. I required a way to log in to my servers efficiently the same way I log in to my online accounts using LastPass.
There is a way of doing this using LastPass, but there was an issue where I love to separate my work and social life (I do have two separate machines for this …). I needed a way to store all the passwords I use during work separately from my mere Gmail and other personal/social account passwords.
Later on, I found KeePass, which I had heard about when working at Safaricom PLC. I never knew it had great perks.
It allows you to store SSH keys and has a plugin known as KeeAgent, which acts as an ssh-agent. It enables you to log in to your servers when the KeePass database file is open without prompting for the ssh-key passphrase.
KeePass has a lot of plugins that do a variety of things, so I decided to look for a way to backup my passwords somewhere, and that’s when I found KeeCloud. It allows you to store a backup in Dropbox and sync the local file with the dropbox file using triggers or manually using the KeePass Synchronize option.
All that being said and done, I need to mention that I will be updating this setup process as time goes by, so if you are reading this blog now or later, check out my Github repository for any updates.
Now let me showcase my work before I end this post. I hope the demo gods will spare me today.
It backups well, I will be using a default install of ubuntu 18 running in a virtual environment. Enjoy!!
Before I end this post, sorry for the shaky video recording, I was using my phone; next time, I will look for better solutions for such situations. Anyways thank you for your time.
In 2020 quarter three, during the covid period, I reconstructed the whole project into single modules. In January 2021, when I was creating some challenges for the Aspire CTF, I deleted my whole 2020 projects directory that I hadn’t backed up to GitHub (Backups are important, BTW). Hence this project will be redone.
- An Introduction to Managing Secrets Safely with Version Control Systems
- Managing dotfiles with Git and Encryption
- Thirty DevOps Tools and Technologies
- Encrypt password files and sensitive info in your git repo
- How to keep your password repository’s sensitive data secure using git-secret
- Password management, cross-platform and in the cloud
- Dropbox setup for dummies
- Remove standard bookmarks in Nautilus
- Project repository