ToddGee.commie

For all of my DreamHost shell users, I've made all their passwords long, random passwords that are (near) impossible to hack.  This makes them near impossible to remember as well, so I use ssh public key authentication for all shell users.

Update: See 1st comment, below.

When we set up whip, our old workhorse server, a couple years ago, we disabled password based ssh logins, choosing to only allow access via public keys.  However, I occasionally needed the ability to access the system when I didn't have ready access to my private key (like when using someone else's / a public computer).  I came up with a system that would enable password-based ssh login for a period of time and then re-disable it.  This post describes that technique.  The system was actuated by a button an internal (private) web page (as described below.  On the same page, had a link to the MindTerm applet, also installed on the server.  This applet, which provides a terminal-like canvas with an ssh session, allowed me to access the server with only a java-enabled browser.

The system was run by a button press on a page.  The page was only accessible via a simple-auth challange (page served over SSL) to prevent shenanigans.  The button called a .cgi script that would, in turn, run, via sudo, anotheand r script that updated the sshd config (allowing password-based logins) and then restarted the sshd service.  This script also forked, the fork sleeping a set amount of time before restoring the original sshd config and (again) restarting sshd.  Note: all paths in these scripts (and related content) are specified with full paths for security.  (Additionally, everything is chmodded as unwritable.) It goes without saying that these paths were particular to the setup on whip...

16 characters:
http://www.pctools.com/guides/password/?length=16&phonetic=on&alpha=on&m...

Introduction

When I first signed up for DreamHost account, I understood, but wasn't overly fond of the way they ran web requests.

All requests to a deployed website on DreamHost are made in the context of the user owning the website.  That is, if a website is deployed under user 'X', calls into that website are performed as user 'X'.  This allows DreamHost to isolate security breaches to the user of the (defective) website.  However, this also has implications for those who use canned software (like Drupal) -- if a defect is found and a website is comprimised, files within that software could be modified as the call is done as the owning user.  Setting restrictive permissions on the file doesn't help as the files are owned by the calling user and (in a truly compromised environment) the file permissions could be modified.  On a traditional system, this wouldn't be an issue as web-initiated calls would be made by the (highly restricted) apache (et. al.) user with permission to only read (and not write) only those files to which it needed to have access.

What follows is the scheme I ended up coming up w/ to work around this issue.  (Other issues continue to exist of course, this is just my solution for this one particular one.)  In this discussion, I'll talk about Drupal sites; but the scheme is the same regardless of what files are deployed on a site.  The initial setup had only my primary user that owned all sites and files.  The files for my Drupal site ("site") were kept in a directory webroot/drupal/<sitename> (relative to the primary user's home directory).