Peter's Blog

I had a need to put an ftp server on my slicehost slice so someone could upload stuff to a site I was hosting. I'd rather avoid ftp as a potential security hole but the alternative is to try to convert them to sftp and also the E editor only supports ftp.

I settled for vsftpd as the ftp server but it took ages to get this person's login to work. I had him set up chrooted to the directory he needed to be in and with his shell set to /bin/false to prevent him logging into a shell. When testing I couldn't log in as him without getting a generic error 530, login denied according to the log file (which didn't feel the need to say why login was denied). Of course my own login was fine.

The answer was in the vsftpd faq, it seems that vsftpd looks through a file called /etc/shells to see if the person connecting has a legitimate login shell and /bin/false wasn't in there. It says this check can be disabled but the incantation didn't work so I had to add /bin/false to the shells file.

I don't quite understand the logic of this design. Isn't it fairly standard to have users who can ftp in but not login? The /bin/false trick was following a precedent from the noble ubuntu/debian distributions.

I'm getting into the habit now of adding any file I edit in /etc to subversion (as noted here), if only as a way to keep track of which ones I have fiddled with. The 95% that I don't need to touch are not in subversion. I like this, I can recall what I did and why (through subversion comments) which will help me restore the system or replicate it. That way, next time I need to install vsftpd I can recall what other obscure system files need tweeking.