7MS #168: Upgrading and Securing Your Digital Ocean Ghost Blog
This weekend, while I was comforting my barfing son, I did some securing and tune-up work on this blog, which is a Ubuntu Digital Ocean droplet running on the Ghost blogging platform. Here's the spit and polish that was applied:
Secure the site with SSH keys
I used this article from Digital Ocean to get the keys applied. Since this was a previously existing droplet and I didn't create keys from the get-go, I skipped down to the part starting with "in order to add additional keys to pre-existing droplets..."
Once that was complete, I made the following changes to /etc/ssh/sshd_config:
- PasswordAuthentication no
- UsePAM no
- PermitRootLogin without-password
Once that's done, do a
service sshd restart or bounce the droplet and you should be all set!
Identified root cause (I think) for 7ms.us crashing every few weeks
I mentioned a few episodes ago that the nginx service for 7ms.us crashed (thus killing the blog) every few weeks and had to be restarted manually. I run two blogs on the droplet, with brianjohnson.tv being the other - and that site never went down! However, I think I found the root cause.
When you host multiple Ghost instances on a single server, the instructions walk you through creating a .conf file in the /etc/init folder for each hosted blog. So for me, I have a bj.conf for brianjohnson.tv and a 7.conf for 7ms.us. But I also found I had what was probably the default ghost.conf file in there as well. Now, I can't be certain that this extra file was causing an issue, but my thought was that perhaps this spawned an extra ghost instance or caused a hung process or service. Maybe. Maybe not. Either way, I nuked it and then researched ways to have the service restart itself if it ever crashed unexpectedly.
Good news is the (hopeful) fix was pretty easy. In the 7.conf file, I added the respawn command, so now my file basically looks like:
#Ghost conf file for 7ms start on startup # Restart if something bad happens respawn script cd /var/www/7 npm start --production end script
After that I did a
netstat -ntlp and found the PID (lets say it was 123) that 7ms was running on. I killed it with
kill 123 and then did the netstat command again to see it was back in action with a new PID. Zero downtime! Cool!