I hate FTP*.  Srsly.

It’s insecure. Passwords are transmitted in plain text. A handful of remote root sploits have emerged in the past and most of them target the daemon from Washington University.

It’s a pain in the ass to work with packet filter, whether you’re connecting to a FTP server behind a firewall or you’re the one behind a firewall.

FTP is a protocol that dates back to when the Internet was a small, friendly collection of computers and everyone knew everyone else. At that time the need for filtering or tight security wasn’t necessary. FTP wasn’t designed for filtering, for passing through firewalls, or for working with NAT.

There are alternatives like FTPS (ftp+ssl) and webdav (although with webdav, you can’t use user quotas). Personally, I prefer scp/sftp as replacement for ftp. The whole session is encrypted. It’s immune to bruteforce through public key authentication. You dont have to memorize passwords. It’s secure as long as nobody gets your private key or nobody discovers a remote buffer overflow for openssh. Using scp/sftp as an alternative to ftp would mean you have to create system accounts for your users. Of course, any sane sysadmin wouldn’t want lusers to have shell access to your servers. You dont want their processes running amuck in your system, wasting valueable cpu cycles. Changing their login shell to /sbin/nologin wont work. Apparently, services that tunnel through ssh (rsync, cvs, etc) require that users have an interactive login shell. How do you do this? I came across rssh.

rssh is a restricted shell for use with OpenSSH, allowing only scp and/or sftp. It now also includes support for rdist, rsync, and cvs. For example, if you have a server which you only want to allow users to copy files off of via scp, without providing shell access, you can use rssh to do that.

Installation is simple. Just change the users’ login shell to the rssh binary and create a config file called /etc/rssh.conf where you define which subsystems are allowed. Supported subsystems and daemons are scp, sftp, rsync, rdist and cvs. The following directives are allowed:

allowscp
Tells the shell that scp is allowed.

allowsftp
Tells the shell that sftp is allowed.

allowcvs
Tells the shell that cvs is allowed.

allowrdist
Tells the shell that rdist is allowed.

allowrsync
Tells the shell that rsync is allowed.

umask
Sets the umask value for file creations in the scp/sftp session. This is normally set at login time by the user’s shell. In order not to use the system default, rssh must set the umask.

logfacility
Allows the system administrator to control what syslog facility rssh logs to. The facilities are the same as those used by syslogd.conf(5) , or the C macros for the facilities can be used instead. For example: logfacility=user logfacility=LOG_USER are equivalent, and tell rssh to use the user facility for logging to syslog.

chrootpath
Causes rssh (actually a helper program) to call the chroot() system call, changing the root of the file system to whatever directory is specified. For example: chrootpath=/usr/chroot will change the root of the virtual file system to /usr/chroot, preventing the user from being able to access anything below /usr/chroot in the file system, and making /usr/chroot appear to be the root directory. Care must be taken to set up a proper chroot jail; see the file CHROOT in the rssh source distribution for hints about how to do this. See also the chroot(2) man page. If the user’s home directory (as specified in /etc/password) is underneath the path specified by this keyword, then the user will be chdir’d into their home directory. If it is not, then they will be chdir’d to the root of the chroot jail.

user
The user keyword allows for the configuration of options on a per-user basis. THIS KEYWORD OVERRIDES ALL OTHER KEYWORDS FOR THE SPECIFIED USER. That is, if you use a user keyword for user foo, then foo will use only the settings in that user line, and not any of the settings set with the keywords above. The user keyword’s argument consists of a group of fields separated by a colon (‘:’), as shown below. The fields are, in order:

username
The username of the user for whom the entry provides options

umask
The umask for this user, in octal, just as it would be specified to the shell

access bits
Five binary digits, which indicate whether the user is allowed to use rsync, rdist, cvs, sftp, and scp, in that order. One means the command is allowed, zero means it is not.

path
The path to which this user should be chrooted

Example:
user=pow:011:10000: # umask=011, rsync only, with no chroot
user=pow:022:00110:”/usr/local/my chroot” # umask=022, cvs and sftp allowed, with chroot

Note that spaces before or after the = sign are allowed, but chrootpath’s with spaces require single or double qutoes.

Problem solved!

*: I’m referring to using ftp with authentication. For me, either run ftpd in anonymous only mode to serve files publicly or dont run it at all. Why can’t it die like telnet? Let’s leave telnet and tftpd to routers and switches and use ssh/sftp/scp to our servers.