================================= Tahoe-LAFS SFTP and FTP Frontends ================================= 1. `SFTP/FTP Background`_ 2. `Tahoe-LAFS Support`_ 3. `Creating an Account File`_ 4. `Running An Account Server (accounts.url)`_ 5. `Configuring SFTP Access`_ 6. `Configuring FTP Access`_ 7. `Dependencies`_ 8. `Immutable and Mutable Files`_ 9. `Known Issues`_ SFTP/FTP Background =================== FTP is the venerable internet file-transfer protocol, first developed in 1971. The FTP server usually listens on port 21. A separate connection is used for the actual data transfers, either in the same direction as the initial client-to-server connection (for PORT mode), or in the reverse direction (for PASV) mode. Connections are unencrypted, so passwords, file names, and file contents are visible to eavesdroppers. SFTP is the modern replacement, developed as part of the SSH "secure shell" protocol, and runs as a subchannel of the regular SSH connection. The SSH server usually listens on port 22. All connections are encrypted. Both FTP and SFTP were developed assuming a UNIX-like server, with accounts and passwords, octal file modes (user/group/other, read/write/execute), and ctime/mtime timestamps. We recommend SFTP over FTP, because the protocol is better, and the server implementation in Tahoe-LAFS is more complete. See `Known Issues`_, below, for details. Tahoe-LAFS Support ================== All Tahoe-LAFS client nodes can run a frontend SFTP server, allowing regular SFTP clients (like ``/usr/bin/sftp``, the ``sshfs`` FUSE plugin, and many others) to access the virtual filesystem. They can also run an FTP server, so FTP clients (like ``/usr/bin/ftp``, ``ncftp``, and others) can too. These frontends sit at the same level as the web-API interface. Since Tahoe-LAFS does not use user accounts or passwords, the SFTP/FTP servers must be configured with a way to first authenticate a user (confirm that a prospective client has a legitimate claim to whatever authorities we might grant a particular user), and second to decide what directory cap should be used as the root directory for a log-in by the authenticated user. A username and password is used for this purpose. (The SFTP protocol is also capable of using client RSA or DSA public keys, but this is not currently implemented in Tahoe-LAFS.) Tahoe-LAFS provides two mechanisms to perform this user-to-cap mapping. The first is a simple flat file with one account per line. The second is an HTTP-based login mechanism, backed by simple PHP script and a database. The latter form is used by allmydata.com to provide secure access to customer caps. Creating an Account File ======================== To use the first form, create a file (for example ``BASEDIR/private/accounts``) in which each non-comment/non-blank line is a space-separated line of (USERNAME, PASSWORD, ROOTCAP), like so:: % cat BASEDIR/private/accounts # This is a password line, (username, password, cap) alice password URI:DIR2:ioej8xmzrwilg772gzj4fhdg7a:wtiizszzz2rgmczv4wl6bqvbv33ag4kvbr6prz3u6w3geixa6m6a bob sekrit URI:DIR2:6bdmeitystckbl9yqlw7g56f4e:serp5ioqxnh34mlbmzwvkp3odehsyrr7eytt5f64we3k9hhcrcja Future versions of Tahoe-LAFS may support using client public keys for SFTP. The words "ssh-rsa" and "ssh-dsa" after the username are reserved to specify the public key format, so users cannot have a password equal to either of these strings. Now add an ``accounts.file`` directive to your ``tahoe.cfg`` file, as described in the next sections. Running An Account Server (accounts.url) ======================================== The accounts.url directive allows access requests to be controlled by an HTTP-based login service, useful for centralized deployments. This was used by AllMyData to provide web-based file access, where the service used a simple PHP script and database lookups to map an account email address and password to a Tahoe-LAFS directory cap. The service will receive a multipart/form-data POST, just like one created with a