TLDR: Login using the built-in console to change the default password. Use the new password to SSH.
The reason you’re getting this error is because you’re trying to SSH into DigitalOcean using the default root password.
Open the Droplet back-end and find the Console button:
Now login from here with root and your default password (Paste it with Ctrl+V). It will ask you to change the password immediately. You’ll have to paste in the default password one more time. Now type in a new password twice. That’s it. You should be able to SSH with WinSCP or PuTTy without issues now using the new password. Enjoy!
After 3 days of trying to figure it out, it turned out simpler than I originally thought. The documentation and other articles are very poor and don’t have examples. In this article, I’m using a domain illozoo.com as a real life example to show you how I did it.
The whole trick with CloudFlare caching S3 files is to trick it you’re serving your S3 files from your own domain or, at least, sub-domain. There is no setting or anything special to be done in Cloudflare after that. Once you setup your custom sub-domain, CloudFlare will automatically start cacheing your files because they are on the same domain. The tricky part is setting it up.
How to Setup:
You must setup custom sub-domain for S3. (using CNAME in DNS)
You must (re)name your S3 bucket “cdn.domain.com“.
(For wordpress: Change your CDN plugin settings)
Instead of serving files from [bucket].s3.amazonaws.com you’ll be using cdn.domain.com
The good news is it’s easy and free to setup 🙂 . The bad news is you’ll need to rename your bucket if it already exists and there’s no rename bucket command in AWS (in 2019, hopefully they’ll add it in the future).
If you already created the bucket and it has content, you’ll need to create a new bucket and move the content to the new one 🙁
1. Setting up custom CDN sub-domain:
All you need to do to serve files from cdn.domain.com is add the following DNS record in Cloudflare. Type: CNAME Name: cdn Content: s3.amazonaws.com
No, you do not need to add the bucket name in front of content. Originally, I thought it should be [bucket].[region].s3.amazonaws.com but it’s really not needed. It will still work but anything you add in front of .s3 will be omitted.
You can now test to see if the cname works by going to https://cdn.domain.com. If you haven’t yet created the bucket you’ll get NoSuchBucket. If you did create the bucket but it’s empty you’ll get AccessDenied.
2. Re-naming your bucket
This is probably the most dissapointing part, since there is no easy way to rename a bucket. The bucket name must be cdn.domain.com.
If you’re starting fresh then there’s nothing to worry about. Just name your bucket that. However, if you’ve already have a bucket full of objects then you’ll have to copy the content to a new one. Create a new empty bucket named cdn.domain.com. Then, you’ll need aws-cli to run the following command and copy all the contents to the new one. aws s3 sync s3://[old-bucket] s3://[new-bucket]
In my case, it was copying with around 9MB/s so on 15GB it will take about 30mins. Alternatively, you can use: aws s3 mv s3://old-bucket s3://new-bucket --recursive
This will move the files from one bucket to the other, instead of coping, so you won’t have to delete the old bucket. It will end up empty.
3. Change Plugin Settings
Finally, if you’re using WordPress don’t forget to change your CDN plugin settings. In my case, I’m using Media Cloud so I had to change the bucket name and add CDN Base URL.
Notes: Keep in mind that you don’t have to use “cdn” as your subdomain. It could be anything you like — “files”, “s3”, “data” you name it. Just make sure matches your bucket name and CNAME. Hope this helps!
I came back home from a friend at around midnight to an inbox full of worrisome emails. First, was the email from the owner of illozoo.com asking what happened to the site. When I visited the site, it was getting redirected to some other malware site which wants you to download a “missing font pack”. It was pretty embarrassing and the worst part about it was that we found out because visitors complained. I was freaking out.
A chrome plugin called Redirect Path came in handy in finding out what’s going on:
After making sure that everything on my server was fine, I saw these 2 identical emails from Cloudflare warning about suspicious activity on the account and it all clicked together.
To top it off, I didn’t get these emails on time because my phone has died 3 hours earlier and my friend didn’t have USB-C charger nor did I bring mine. A series of unfortunate events.
I quickly logged into Cloudflare, enabled developer mode which bypasses everything, and after going through the settings I found two 301 Redirects to a bit.do shortening service. ( with wildcards to cover the entire domain, sub-domains, dirs, www and non-www version — pretty simple and evil)
301 Redirect = Nightmare from hell
If you’ve ever dealt with a permanent 301 redirect, you probably know it’s the Devil’s work. Once a browser caches a 301 Redirect it does cache it permanently… as in forever. It’s amazing that browsers to this day behave in this way. The only way to “refresh” a cached 301 redirect is to clear your browser cache. Not just force refresh using Shift+F5 since there is no way you can press theses buttons while on the domain. It will get redirected before you press it. You’d need to clear cached images and files (Using Ctrl+Shift+Del on Chrome on Win). Requiring every affected visitor to do this just to fix your website is unacceptable. That’s how a hacker can completely toast a high-traffic domain name overnight without ever getting a hold of the domain. Fortunately for me, browsers also honor the expiry date of a redirect and Cloudflare has their set at a fixed 1 hour. This is the only thing that saved me.
To summarize, the clean-up was pretty straight-forward:
Remove the 301 redirects from Cloudflare.
Change password and enable 2-factor authentication on the account.
Wait 1 hour for the cached redirects to expire.
Disable developer mode
Although I didn’t have the balls to run the fontpack.exe file from the malicious website on my machine, I ran an online test using virustotal.com and sure enough it was packed with “goodies”. (Notice that from the time of making the screenshot until the day of writing this article more antivirus groups have caught up to it)
Finally, I wrote a quick note to bit.do and they were kind enough to remove the shortened URL from their service:
My initial reaction was to blame it on #cloudbleed but after getting familiar with what it affects, it seems like this may be unrelated to it. Could it be that it’s just my account that got affected due to weak password? I highly doubt it. I’m using LastPass to randomly generate 16-bit alpha-numeric with special characters passwords and if my lastpass master pass was compromised, a lot more damage would have been done. What I’m definitely blaming Cloudflare for is being unable to require some additional identification upon identifying the suspicious login activity. Sending an email is simply not enough. Lastly, once they identify suspicious login why would they allow them to set up 301 redirect on the entire domain? This could have been thought out more thoroughly. Even if it was really me doing it, I wouldn’t mind having to confirm this action over email. I don’t know… I’m not a security expert but I’m not the only one with this problem and i’m sure they’re aware of it:
It automatically creates a MySql database and User using the provided information; Downloads the latest version of WP and unzips it; Changes your config-wp.php to work with the newly created database. Uses SSH2 to connect to shell.
Feel free to use it as is or modify it to your needs. Please report bugs and fixes.