Enhanced Security Enabled by Dreamhost


On 2 accounts, enhanced security was enabled without my knowledge or notification by dreamhost last night, breaking all of my websites. I was using a ‘clever’ security method with one way enhanced security that uses a ftp only account WITHOUT enhanced security and all the other users WITH enhanced security. My FTP only accounts were ‘enabled’ with enhanced security last night by DH without notification. Websites that were working last night broke this morning. If DH does this could they at least give us a heads up?


Interesting. Mine as well. I have been experimenting with this, so the only site that was affected was a low-traffic site which I don’t care much about. I also use your method to share some rc files and working on having a common base for cronjob scripts.

But I can confirm that I didn’t make this change.

It would make sense if DH sets this as the default option for all new accounts. In fact, I would encourage that. Maybe they are going through and setting all existing accounts that was since so many are wide open and not for an legitimately good reason?

Fortunately it’s possible to go back:

It would have been nice to get a warning of this unilateral mod.


Hmm, must just be for shared hosting. I, like the both of you, have been doing some experimenting and the account I setup for doing the sFTP off-loading of my rsync backups is ok but it’s on a VPS.



I think I had mine enabled but it was never really working. Just noticed the same issue today as I use a script which checks all my other websites, but it failed due to “enhanced security” changes.

And yes, they should tell us.


If you had enhanced security enabled, but you were able to scan all of your accounts from one user, that could have only been done by making each user’s home directory world-readable. That doesn’t sound good!

The problem with enhanced security is that it doesn’t prevent someone from chmod -R 777 ./* out of frustration of not understanding permissions and groups (I’m guilty!) in order get something working.

Anyway, the fact that DH didn’t mention anything and just did it might be indicative of a breach or discovery of a security flaw. The same sort of behaviour occurred with the log files and webFTP, remember? Since it’s pretty easy to get an account, and even easier to scan other user’s home directories on the same machine, maybe some hackers decided it would be more effective to try the inside doors rather than looking for weak WP plugins.


It’s mandatory - I’m outta here.


And so the functionality of DreamHost shared accounts plunges further toward the level of any two-bit $3/m shared host.



Yeah but at least there will be some funny article in the dreamhost newsletter. “Hey we were noticing that some of you were trying to protect yourselves against hackers! What a Hoot! We decided to play also and help by sticking out noses in without context and screwing up your work! Aren’t we just dreamhosty!”

No notice mind you, just some smart alecky blurb entry from Simon.

Or more realistically,

"Welcome to April, as we are expanding two both coasts we’ve divided up all our resources and shipped half of our people, all the talented ones to new york to work on our shiny new datacenter, meanwhile we’ve hired trolls from the local rent-a-university and explained to them what it means to login; they are now in charge! Isn’t it awesome! That’s why our service is in the crapper! Literally, we’ve moved our customer support into the men’s room here in LA!

All the best,


I think the fact that it’s been a quick, quiet move realistically means that they’ve discovered something that could be or is being exploited and they are trying to plug it first and answer questions later.

There seemed to be some roboscript trouncing through my server as I was setting everything back because I started seeing some weird things. My .ssh keys no longer worked because their perms had been changed to 644 which means they won’t work. They worked just a few minutes before. Also, the ability do do a directory listing in my shared_resources user seemed to come and go…

I give up for now. Something’s going on, and I hope DH is in the driver’s seat right now.


Dreamhost, I really hope you are in control of my server right now. I have two sessions open with the same user, one has been logged in for a while, one just now

in one terminal (just logged in):

$ ls -alth /home/commmonuser ls: cannot access /home/commmonuser: No such file or directory
but the other terminal (same user, has been logged in for some time):

$ ls -alth /home/commonuser total 104K -rw------- 1 commonuser pg2222222 7.7K 2012-03-29 19:42 .bash_history drwxr-x--x 702 root root 20K 2012-03-29 01:53 ../

What’s going on?


SSH keys to my ftp only host have also been changed. Also the enhanced security was enabled at around 2:54am Pacific time.


Maybe the ‘enhanced security’ setup was a bit bugged and it caused everyone to be in the same group of ‘secure’ users. Or it just wasn’t applied properly. Either way it seems to work now and I am rewriting my scripts to reload remotely from a central server and just eval() the code and execute it locally on each site. It means dropping a tiny file into each site, but it is no worse security-wsie than a hacker getting in and doing whatever they feel like - assuming I write safe code!..


Well, that’s certainly a way to get around it. It makes me shudder though. I think I’m going to go back to investigating ssh-agent and public keys. I think doing everything within the system rather than jumping outside of it is inherently safer…

BTW, I assumed that the reason each user’s home directory was assigned to the adm group was because no one was a member of the group. I certainly wasn’t a member, so it didn’t matter what the settings were, group-level wouldn’t work. Perhaps people went with o+rwx to get around it because they didn’t understand it? I know I tried and gave up on groups for quite some time when I first got started and even tried chmod 777 a few times out of frustration.


The reason we’re setting home directories to “adm” is because the web server user (“dhapache”) is a member of that group. The web server accesses your files while running as dhapache, not as your user, so it needs to have access to your files.



Any explanation for why the account were changed two days ago?