About This Series
Follow along as I get more familiar with managing my own servers. In this series I’ll be using DigitalOcean as my playground and learning how to setup Nginx, MySQL, NodeJS, firewalls, etc.
Why Server Admin?
My interest in managing my own servers grew while working on a large saas product.
I spent a lot of time on the frontend as well as the backend API working with Angular and Laravel, but I saw first hand how important it was to have developers familiar with server admin.
We were a small team, and the company wasn’t in a position to bring on a full time server admin. Instead, a few of the senior backend developers filled the role. They did a fantastic job, and their skills were extremely important to the health of our start up.
For myself, I’d like to be able to take an app from planning to production on my own.
So far the journey to learn about servers has been challenging, but not as hard as other things I’ve had to learn about (like algorithms). So be encouraged by that.
Follow along, please. I think you’ll find the journey as rewarding as I have.
Two of the best resources I’ve found so far:
SFH Crash Course is a must-watch. Really. Watch it and come back here to thank me. Oh yeah, you should thank @fideloper
I also purchased his SFH Book + Video package
. I haven’t made it all the way through, yet, but I’ve learned a ton so far.
The material is really well done.
The Free Crash Course
on Servers for Hackers is a great place to start.
Chris explains the various types of servers available and walks you through the basics of setting up a server on DigitalOcean.
You can open your own DO account to follow along, or you can also use a free tool like Vagrant and VirtualBox to setup a server on your computer.
If you’re a complete newbie, you may find it easier to just follow along on DO. $5 will get you started.
Some Foundations That Have Helped Me
Understanding SSH keys and how they work was a gap I needed to fill.
Here is a decent video
I found that explains them pretty well.
In sum, you have a private key and a public key on your computer. The public key is what you can share publicly. The private key stays on your machine and should never be shared. When connecting to something with which you’ve shared your public key, a handshake of sorts happens between your private key and the public key. Authorization happens when that handshake is successful.
Prior to this journey, my only experience with SSH keys was pushing / pulling code from Github. Now I know a bit more about how / why they work.
When you create your DigitalOcean droplet, you can set it up to authenticate using an SSH key you have. If you do this, you won’t get an email with a password to login; instead, you’ll identify yourself using the private key you have on your own computer when using SSH to login through your terminal.
Here’s how you can get started:
- Create a new SSH key on your computer.
Using a new key is a good idea. You may have other keys from working with Github, etc. and you’ll likely find it easier to manage your keys if they are single-purpose.
Be sure to name your key appropriately, too, so you’ll easily remember where you’re using that key. Something like “my_test_do_droplet” will do.
Once created, you’ll get two keys in your .ssh directory: “my_test_do_droplet” and “my_test_do_droplet.pub”
Open a terminal and type the following:
ssh-keygen -o -a 100 -t ed25519 -f my_test_do_droplet
For more details on what you’re actually doing with that, look here
. If that article looks intimidating, here are the important bits as I understand them:
“Generate a key using the option (-o) or the new RFC4716 key format and the use of a modern key derivation function powered by bcrypt. Use the -a option for amount of rounds.”
… not too sure what all that means, but it sounds good.
Next if you look at the “man” page for ssh-keygen you’ll see that using ed25519 with the -f option allows you to set the name of the output key file, ie: my_test_do_droplet
Now, after all that, your key will be in your home directory in a sub directory called ‘.ssh’.
I’m on Ubuntu, so my keys are found in ~/.ssh
- Add your new key (the public, .pub, version) when creating your new droplet.
You’ll see this option when creating your droplet.
By the way, I recommend creating a droplet with the Ubuntu version Chris uses in the SFH Crash Course videos. It will just make things easier.
- From there, you can login over SSH to the IP visible in your list of droplets.
ssh -i [email protected]_IP_ADDRESS
If you’re in your .ssh directory, simply type:
ssh -i my_test_do_droplet [email protected]_IP_ADDRESS
When you first login your home computer isn’t going to recognize the remote computer. You’ll be prompted to add the remote machine to your list of “known hosts”.
This is an important safeguard; it is a way for your machine to make sure it’s talking to the correct remote server. If you ever see this message again and you’re not expecting it, don’t login until you’ve verified that you’d be logging into the correct machine.
If you’re following along I highly recommend you open a new text document and keep track of some of this stuff. Be sure to continue updating it, adding your own comments as we go along. I guarantee that creating cheat sheets like this will help you in the future.