Terminal Ghost

Ghost designed by Mister Pixel from the Noun Project

My exploration of the blogging platform Ghost continues, and this is yet another post in that vein. It might be worth mentioning, however, that my experimentation with Ghost is in service of trying to figure out a cloud-based infrastructure servce like Amazon’s EC2. Having something concrete to work with, such as this micro isntance of Ghost, pushes me to figure out the specifics of how I would manage an application in this environment. This is all the more important given DTLT will be piloting Amazon Web Services alongside UMW’s IT department this summer. It’s exciting to think this might be the next generation sandbox for our group, and I wanted to actually experiment in this space myself. I’m tired of the rest of DTLT having all the fun 🙂

This post, however, is a bit less grandiose that all that. Here I’ll simply recount my feeble attempt at command line after locking myself out of the Ghost blogging application. Turns out Ghost has a bit of a design flaw. Sending email doesn’t work out-of-the-box, as it does in a LMAP environment. So you need to configure a cloud-based email service, such as Mailgun, Amazon’s SES, or Gmail in order to get emails sent to you for, say, retrieving or changing a lost password. But that’s not necessarily the flaw, the problem is when you click the “Forgot Password” link it automatically changes your password and send it to you, regardless of whether your email is setup or not. Shouldn’t you have to click on some kind of confirmation link in the email for such a function to hanppen? So, turns out, anyone who clicks the “Forgot Password” link can change your password. Not so good.

I experienced this problem first hand when I clicked th “Forgot Password” to test if the Mailgun account I set up worked (more on this in another post). Failing to get the cloud-based email to work, I decided to try and access the database and change the password there. After a bit of exploration in via SFTP, I discovered where the database for Ghost is located: ../ghost/htdocs/content/data/ghost.db. I still needed to edit the database, and Tim Owens turned me on to the SQLite Database Browser which is pretty slick and edabled me to find the password hash within the user table.

Ghost uses bcrypt to encrypt passwords, so I used this bcrypt hash generator in generate a bcrypt hash from a password I entered—very cool. At this point I thought I was golden, I entered the hash and saved it to the server, but no go. I tried this several times in several differetn ways, but it would not work.

I’ve had issues with permissions in regards to FTP before, so I figured it was time to start doing some of this stuff via terminal. I had to brush up on my Terminal 101 skills when it comes to file permissions and the like, but as much as I bitch I know it’s good for me. One of the things I apprciate is that I figured out how to SSH into a virtual server using Amazon’s keypair. I had put my Amazon keyair in the ~/.ssh folder on my computer, so know that I found this post that explains how to SSH into your EC2 instance. It looks something like this:
“ssh -i path/to/amazon.pem bitnami@ec2-54-84-245-2.compute-1.amazonaws.com“

I did this, but I got a “Permission denied (publickey)” error, so I had to do the following:
“sudo chmod 600 /path/to/amazon.pem“

After that I was in. I quickly remembered how the ‘cd’ and ‘ls’ commands work in terminal, and navigated to ../ghost/htdocs/content/data/.
From there I used these two posts to edit the database and reset the password. Given I was already in the data directory, I entered the following:
sqlite3 ghost.db
And then
sqlite> update users set password="generatedbcrypthash" where id = 1;

But when I did this I got the following error message:

Error: attempt to write a readonly database

Turns out in It was a permissions issue afterall, and the issue was I needed to change the permissions for the /content and /data directories, as well as the ghost.db file. Once I changed those permissions,I could finally change my password. Here’s how I changed those permissions—-one by one, mind you (I know there are better ways to do just about eveyrthing I did, and I am more than open to advice and recommendations on the comments 🙂 ):
sudo chmod 777 ghost.db
and move up a directory and
sudo chmod 777 data
and move up another directory and
sudo chmod 777 content

Also, given this is not safe at all, it’s essential that after you change the password, you revert the permissions back to 775 for the directories and 644 for the files.

And that’s it. I never learned so much changing a password in my life.

Credits: Ghost designed by Mister Pixel from the Noun Project