This may be related to my previous post about Regaining Access to DigitalOcean Droplets, but I think I'll write up the whole experience, as there seems to be many different issues I encountered (almost randomly).
I stated in that post that I had to reformat my main PC and set up the SSH Keys again in order to access the droplets. But it turns out there was a lot more going on.
As all good developers should do, my websites are encrypted with an SSL certificate; it's just good and common practice nowadays, and with that, increase the security of the sites. This means reviews and editing the files permissions, and setting up the correct keys and passwords to gain access to the server.
There are numerous different providers out there to certify your site; some are free, some are paid, and some may even come from your hosting provider. But that's not what I'm getting into today.
What I'd like to tell you is to make sure that your site is pointing to the correct directory on your site.
It sounds simple, I know, but I was having issues with redirecting my site to the secure version, and it was a simple matter that my Apache2 config files were pointing to the wrong directory.
It was a quick fix, some tweaking in the config files to make sure every attempt to access the site went to the correct place.
Granted, if you're not one who plays around with the config files, you should be able to get support from your service provider (if not, feel free to get in touch and I'll see if I can point you in the right direction).
More often than not, my clients want "WordPress sites", and sometimes it requires working with other developers or hosting providers who may or may not have things set up correctly. This can be a nightmare at times.
After a lot of research, testing, and hair pulling, I think I've got the access permissions set up in a way which is secure and functional.
Most servers use www-data for the user and group for their sites. Let's assume this is the same for you.
Your "website" folder needs to have the owner and group set to www-data. This will allow your website to own these files and folders, to view and make editions (if you've allowed it).
You can limit www-data to view only, but then how could you upload files via a media library, for example.
Here comes the more infuriating part. The read/write permissions for files and folders.
Again, in your website's folder, I would recommend that the permissions are set to 755 for folders, and 644 for all files within the main site directory.
It would also be beneficial to "hide" any config files (the files that hold connection details) from the public. The www-data user will still be able to access them, but not some randomer whose stumbled across your site.
This all came about because I wanted to make my site secure with a certificate. I never gave it much thought for myself, because I was just running a "portfolio site", but I wanted a way for people to communicate with me.
So I had a contact form, which quick became bombarded with spam, so enter in reCaptcha, then that needed to be on a secure site.
So I install a certificate, only to find it's not working, that I can't make changes, and what-not.
None of these were major issues, but all added up, it can cause a lot of work.
Also the fact that I couldn't use my IDE to access my server using the SSH Keys. I had to in-fact convert that key into a PPK file and use that!
It wasn't a huge problem, but an inconvenience because of a bug with PhpStorm.
Just some FYI there.
I'm pretty sure I'll find more bugs as time goes on; from new and old features alike, but hey, who said the life of a developer was boring?
Running a cost effective business is always an important thing, and for a few years I had a re-seller account with a UK company.
They were a brilliant company to work with, always on hand to provide support, but they couldn't provide me with exactly what I needed, nor could I justify the large expense when I couldn't recuperate it from my clients.
I had a few clients who used/needed dedicated servers, so I had gained a fair amount of experience through this, and after some research and trial runs, I finally settled on DigitalOcean because it was the easiest and cheapest service out there.
I know there are cheaper and "better" providers out there, but I tried so many and a lot had hidden costs, support was terrible, and quite frankly made working with the servers more of a chore. DigitalOcean, in my opinion, just made it a whole lot easier.
I'm not paid for this article, but if you do want to set up your own DigitalOcean account, you can use this link and I'll get a kickback from it.
Or contact me and I'll manage it all for you.
After trying to help a friend fix their computer, I think I may have inadvertently infected my own computer with the same problem. It could have been a coincidence, but I had to reinstall the OS on my main system, and with that, I lost the SSH Keys I used to access my servers.
So, here I am... locked out of my own systems, and the only access I have is through a in-browser console/terminal which was sluggish and not very reliable.
My services were up and running, everything was running fine, but I could not access the files on the server; it wasn't a good situation.
DigitalOcean has a section where you can paste your SSH Keys, so whenever you start a new Droplet, they are automatically added to the Droplet.
DigitalOcean also, by default, allows you to login via a username and password, which a) isn't the most secure method, and b) needs to be reset.
Now, I'm not sure if I had forgotten my password or if I was ever given the chance to set one, but when I lost access using SSH, I needed to reset the password in order to log into the in-browser console.
You may be thinking "wait, why did you lose access if you can login with a username and password?"; well, simply put, I disabled that method of access to increase security, so the only way was using SSH Keys.
After hours of research and trial and error, I came across this article which helped me figure out a way to gain easy access to the droplets again.
The in-browser console was not fun to use; practically unusable because of the glitches and bugs. So the main focus was to enable access remotely once again.
Here are the steps which I follow:
This will allow you to log in remotely using the username and password. Now I can copy and paste my SSH Key(s) directly into the server.
This was impossible using the in-browser console as the key was not copied over correctly.
You will now be able to log into the Droplet remotely with the SSH Key, once we disable access via Password again.
To do that, follow the first set of steps, but this time set PasswordAuthentication to No.
Once reloaded, you should be able to access the Droplet again, securely, using the SSH Key only.
Although no solution is perfect, disabling password authentication restricts anyone with the password from gaining access to the server. I believe that DigitalOcean is secure enough as to stop people from gaining access via the in-browser console, but say someone finds out my password for a Droplet; they can simply log in from anywhere and do anything.
SSH Keys create a link between the computer and the server, so as long as there is a link there, the server will allow access from that computer. If there is no link, access is denied.
So, even if someone gets the password, there is no link between computer and server.
