SFTP only chroot users with OpenSSH in Debian

From OpenSSH version 4.9 and up it is now possible to create chrooted SFTP-only users with OpenSSH without the need for any add-ons.

In my example i want all users within the “sftp” group to hit /srv/sftponly.  This can be done on userlevel or on group level. I will be using groups.

At first, use your favorite editor to ecit /etc/ssh/sshd_config and find the line starting with “Subsystem sftp” (usually at the bottom) – change it so it looks like this:

Subsystem sftp internal-sftp

Next, we need to add the rule to match users. Add this to your sshd_config at the bottom:

Match Group sftp
PasswordAuthentication yes
ChrootDirectory /srv/sftponly
AllowTCPForwarding no
X11Forwarding no
ForceCommand internal-sftp

Now add the sftp group:

groupadd sftp

Add our first user:

useradd -d /srv/sftponly -g sftp -s /bin/false <username>
passwd <username>

Now, restart openssh:

/etc/init.d/ssh restart

And you should be all set. Use your favorite SFTP editor to test. Also try logging on via SSH to make sure that the user does not have access to do that.

Troubleshooting

Along your way some problems might occur. I will try to address the most common ones here. At first what you want to do is enable debugging in openssh so you can see in the logs what happens. Edit /etc/ssh/sshd_server – find “LogLevel” and change the setting to “DEBUG” – and restart ssh. The problems below are shown either in these logs or in the output of the “sftp” command from the client. When using the sftp client be sure to add the “-v” flag for verbose output.

Problem: fatal: bad ownership or modes for chroot directory component “/”
Fix: chmod 755 /

Problem: fatal: bad ownership or modes for chroot directory “/srv/sftponly”
Fix: Folders in the path along the way must be owned by root:root and must not be writable by anyone but root. This is because the directory we are going to use will be the root of the new users.  In my example the fix would be: chown root:root /srv ; chown root:root /srv/sftponly ; chmod 755 /srv ; chmod 755 /srv/sftponly”

Problem: Everything seems to be OK.. The users just don’t get access.
Fix: Make sure that you don’t have any whitespaces in your sshd_config after the configuration lines. In my case this caused a real pain.

Hit me a comment if you experience anything strange.

Setting UMASK for SFTP users

Add this line to /etc/pam.d/sshd:

session    optional     pam_umask.so umask=0002

This particular line will make new files/folders user and group writable.

Do you make backup? – If you do, is your backup strategy safe?

I think server backups here.

As a server administrator, there are a lot of concerns and one of the bigger ones is security. I know a whole lot of server administrators, and when I did a Q&A to know about their backups I was astonished to find out that more than 30% of them did not even take backup. I got a lot of responses and there are many ways of handling your backup, but a lot of them are very very wrong and will not do you any good in case of an emergency.

Do you even back up?

If you do not back up your data, what will you do in case of a hardware failure? Sure, you might be running a RAID, but a RAID is no guarantee, a RAID can break and then you will loose the game.

If you do not take backup, what will you do in the event of a fire breaking loose and destroying everything where ever your server is placed? Is your data valuable to you?

How do you back up?

Making backup is good. But how do you save your backup on the remote host? A few common ways of making backup is via FTP/SFTP/rsync. So, now you’re safe, right? If a fire breaks out, water disaster, disks die and so on, you will have your backup. And that’s good.

If your backup is automated, then your client somehow authorized to the backup server. In most of the above mentioned cased that authentication gives you full access to the backup data! Why is that bad?  It is because an attacker that has success gaining access to your server, will be able to emulate the authentication of the automated backup and therefore be able to delete both production data AND backup data.

How much is your backup worth now?

Maximizing Password Security

Amongst several years I have been using very complex passwords, however they could somewhat be linked to each other. I memorized around 15 different passwords with an average length of 15 chars. All of them had a complexity level which was rather high, (at least 3 of these: uppercase letters, lowercase letters, numbers, special characters, whitespaces).. So, from these I created passwords put together from them and so on.

But really, does that maximize my password security?  No, not really, because using the same password two places no matter what increases the risk of a password to be compromised. Even though both places kept the passwords in some encrypted format, there would still be 2 paths to reach my hashes. So, the only way of really solving this issue is by having a different password _everywhere_ and not use 2 equal ones anywhere. This leads to some kind of challenge. I would never, ever use a passphrase like “I am awesome for having a long password”..  So the solution would be to have a password database, containing all the different passwords used. For this I chose KeePassX – the OS wide port of KeePass.

This has a nice password generator, so I genereated a 28 character, random password containing lowercase letters, uppercase letters, numbers and special chars. Now I have memorized that password. The database is 256bit AES encrypted.

So now I do not use any password that matches one I use somewhere else – furthermore, all passwords are 15-30 chars long with maximum complexity level.. Well, at least those who are not for stupid pages which has a.. MAXIMUM complexity level. How stupid… Anyway, I’d like to share my keepass multiOS, portable package with you.

The contents are:

KeePass 2.08
The windows version – portable.

KeePassX 0.4.0 Linux 32-bit
The Linux version, compiled from source using GNU/Linux Debian Lenny.

KeePassX 0.4.0 Linux 64-bit
The Linux version, compiled from source using GNU/Linux
Ubuntu Jaunty.

KeePassX 0.4.0 Max OS X
The OS X version .app package. Works like charm.

All of them are tested on the respective platforms, and works like a charm. You can fetch the package I made right here:
http://frands.net/pub/Keepass_MultiOS.zip