SSH Configuration Mistake – How I Locked Myself Out of My Own Server

This site and a bunch of my other sites were down yesterday. I am slightly embarrassed as to the reason why. All the same, I will share what happened, hoping that it might save someone else the trouble I caused myself. This was a true newbie mistake on my part…

I was working on “chroot’ing” another user of my server. I was setting them up so they only had SFTP access and that when they logged into the server via SFTP they would be “jailed” into one particular sub-directory. This is a very common security practice. The setup changes are made to the SSH config file. Remember that my web-server is “all my own” for better or for worse… and in this case it was “for worse…” Furthermore, I can only access my server remotely via SSH. So I should have been much more careful messing with my SSH config file. Alas, I was not…

So I set the following directives in my SSH config file located at:
/etc/ssh/sshd_config

These settings were based on an article I was reading on Chrooting users… (Account and Group names in the below settings were changed for security/anonymity). Anyone that has done a fair bit of configuration will see my mistake immediately (look at the settings for “myaccount” user/group)…

Couple of things…

First… when you use the “AllowGroups” directive… any groups that aren’t listed will be denied. SO MAKE SURE YOU ADD AT LEAST ONE OF YOUR OWN USER GROUPS!! – which I did…

Second… I was under the mistaken impression that each group listed in the “AllowGroups” directive had to have its own “Match Group” directive/section. They don’t unless you are trying to Chroot or set something else up. This was my first mistake as I set a section up for myself.

Third… I thought I was doing things correctly… I wanted my user to have access to the whole file system so I set the Chroot directory to “/”. That was fine and it would have been okay except…

Fourth, the darn “ForceCommand internal-sftp” directive… which I didn’t understand and just blithely copied into each user I wanted to Chroot… Let me explain what this directive does… which might be painfully obvious… it forces the user to use SFTP… and ONLY SFTP.

Had I not included this directive I would have been okay. However I did include that directive and once I lost my SSH connection I could not longer get a shell for my user account. I couldn’t modify the config file via SFTP either because “myaccount” is not the root account, rather it is an account that has sudo access. Sudo (I learned after some research) cannot be easily invoked for SFTP connections/access without setting up several things beforehand.

So I was effectively locked out of my own server. I don’t have remote console access so I had to wipe it and reinstall Ubuntu. Luckily I had all of the good stuff backed up to a second server so I didn’t lose data and I got to test my recovery procedures which actually went fairly smoothly.

So, lesson learned… I might write a cron job that automatically copies an SSH backup file over the main file every hour or something… that way I can test ssh settings more fully with some degree of impunity in the future. For the time being, I hope you are laughing at me… rather than crying because you found this article and are in the same situation…