From: Daira Hopwood Date: Tue, 6 Jan 2015 19:14:47 +0000 (+0000) Subject: Update docs for SFTP public key auth. refs #1411 X-Git-Tag: allmydata-tahoe-1.10.1a1~86 X-Git-Url: https://git.rkrishnan.org/components/com_hotproperty/frontends/statistics?a=commitdiff_plain;h=0d935e858964b646c4ccbca5b2a1c0be97addf34;p=tahoe-lafs%2Ftahoe-lafs.git Update docs for SFTP public key auth. refs #1411 Signed-off-by: Daira Hopwood --- diff --git a/docs/frontends/FTP-and-SFTP.rst b/docs/frontends/FTP-and-SFTP.rst index 4d174d59..f8c9e350 100644 --- a/docs/frontends/FTP-and-SFTP.rst +++ b/docs/frontends/FTP-and-SFTP.rst @@ -51,13 +51,12 @@ 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.) +A username and password can be used; as of Tahoe-LAFS v1.11, RSA or DSA +public key authentication is also supported. -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. +Tahoe-LAFS provides two mechanisms to perform this user-to-cap mapping. +The first (recommended) is a simple flat file with one account per line. +The second is an HTTP-based login mechanism. Creating an Account File ======================== @@ -67,14 +66,17 @@ 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) + # 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. + # This is a public key line: username keytype pubkey cap + # (Tahoe-LAFS v1.11 or later) + carol ssh-rsa AAAA... URI:DIR2:ovjy4yhylqlfoqg2vcze36dhde:4d4f47qko2xm5g7osgo2yyidi5m4muyo2vjjy53q4vjju2u55mfa + +For public key authentication, the keytype may be either "ssh-rsa" or "ssh-dsa". +To avoid ambiguity between passwords and public key types, a password cannot +start with "ssh-". Now add an ``accounts.file`` directive to your ``tahoe.cfg`` file, as described in the next sections. @@ -90,8 +92,7 @@ password to a Tahoe-LAFS directory cap. The service will receive a multipart/form-data POST, just like one created with a
and fields, with three parameters: -• action: "authenticate" (this is a static string, for backwards - compatibility with the old AllMyData authentication service) +• action: "authenticate" (this is a static string) • email: USERNAME (Tahoe-LAFS has no notion of email addresses, but the authentication service uses them as account names, so the interface presents this argument as "email" rather than "username"). @@ -105,6 +106,8 @@ makes it harder for attackers to brute force the password or use DNS poisoning to cause the Tahoe-LAFS gateway to talk with the wrong server, thereby revealing the usernames and passwords. +Public key authentication is not supported when an account server is used. + Configuring SFTP Access ======================= @@ -201,6 +204,8 @@ if you connect to the FTP server remotely. The examples above include ":interface=127.0.0.1" in the "port" option, which causes the server to only accept connections from localhost. +Public key authentication is not supported for FTP. + Dependencies ============