|Main | News | Documentation | Contact Us | Download | Links|
I work as a contractor at the United States Department of Agriculture in D.C. I'm a Linux / Unix system admin. one of my duties is to run the agency public web server and the development (staging) server for the web content. This development server runs a secure ftp server (using openssh) that is available to our web content developers as the means by which they upload and make modifications to the web files. The developers use Dreamweaver and F-Secure as the ftp client. We run a fairly large site (25,000+ files) with mixed static content that gets a pretty good volume.
The way the server is set up is that the developers have their own user accounts and they belong to various system groups that have read/write access to various parts of the directory structure that contains the web content. The developers use F-Secure with their username and password to authenticate and log in to the server, at which point they are able to navigate to the appropriate folders and upload their files.
The read/write bits on the files are set 664 (owner and group read and write). It's important that this mode does not change, because it could potentially prevent members of the group from modifying the group's content. With stock openssh software, the ftp client is allowed to modify this file permission mode ... Hence the "umask" functionality of my patch.
Directories have a specific mode that cannot change, as well. They have the sticky bit set so that the developers are able to add files with the appropriate ownership.
The ownership of files is important too. The group owner must always remain the same so that, again, each developer in the group is able to modify content as needed ... Hence the "chown/chgrp" functionality of the patch.
The annual security plan for our Agency requires "individual accountability via audit trail for all individual who work on agency-critical data." Stock openssh software does not do any logging of ftp transactions ... hence the logging functionality of the patch.
I developed the patch about three or four months ago. I use it on, not only our web development server, but on each of my Linux servers (because I've got openssh installed on all of them in order to give me a network administrator login). I have things logged to /var/log/sftp.log, but the choice of log file is whatever you want it to be. I added sftp.log to the logrotate conf file, and it gets rotated and zipped at the end of each month. The sftp log file on the web development server, which has the most sftp traffic, grows to about 750k each month.
One of the reasons I decided to submit this patch as a project to sourceforge, is because some of the people using the patch were complaining that it doesn't work with the "chroot ssh" patch ( http://chrootssh.sourceforge.net, so I figured it would be worthwhile that if I am going to maintain this thing, have it on a public website so folks can check for updates.
|http://sourceforge.net is hosting this site|