Node:sfsauthd_config, Next:, Previous:sfsrwsd_config, Up:SFS configuration



sfsauthd_config--User-authentication daemon configuration

Hostname name
Set the Location part of the server's self-certifying pathname. The default is the current host's fully-qualified hostname.
Keyfile path
Tells sfsrwsd to look for its private key in file path. The default is sfs_host_key. SFS looks for file names that do not start with / in /etc/sfs, or whatever directory you specified if you used the --with-etcdir option to configure (see configure).
Userfile [-ro|-reg] [-pub=pubpath] [-mapall=user] path
This specifies a file in which sfsauthd should look for user public keys when authenticating users. You can specify multiple Userfile directives to use multiple files. This can be useful in an environment where most user accounts are centrally maintained, but a particular server has a few locally-maintained guest (or root) accounts.

Userfile has the following options:

-ro
Specifies a read-only user database--typically a file on another SFS server. sfsauthd will not allow users in a read-only database to update their public keys. It also assumes that read-only databases reside on other machines. Thus, it maintains local copies of read-only databases in /var/sfs/authdb. This process ensures that temporarily unavailable file servers never disrupt sfsauthd's operation.
-reg
Allows users who do not exist in the database to register initial public keys by typing their UNIX passwords. See sfskey register, for details on this. At most one Userfile can have the -reg option. -reg and -ro are mutually exclusive.
-pub=pubpath
sfsauthd supports the secure remote password protocol, or SRP. SRP lets users connect securely to sfsauthd with their passwords, without needing to remember the server's public key. To prove its identity through SRP, the server must store secret data derived from a user's password. The file path specified in Userfile contains these secrets for users opting to use SRP. The -pub option tells sfsauthd to maintain in pubpath a separate copy of the database without secret information. pubpath might reside on an anonymously readable SFS file system--other machines can then import the file as a read-only database using the -ro option.
-mapall=user
Map every entry in the user database to the the local user user, regardless of the actual credentials specified by the file.

If no Userfile directive is specified, sfsauthd uses the following default (again, unqualified names are assumed to be in /etc/sfs):

Userfile -reg -pub=sfs_users.pub sfs_users

SRPfile path
Where to find default parameters for the SRP protocol. Generate such a file using the "sfskey gensrp" command. The default is sfs_srp_params. If the default file does not exist, serving pre-generated SRP parameters is disabled.
Denyfile path
Specify a file containing a list of users that are to be explicitly denied the ability to register and update keys on the authserver. The default is sfs_deny. If the default file does not exist, we assume an empty list.
Realm name
Define the realm to which this authserver will belong. Authentication information (including SRP) can be shared amongst authservers that are in the same realm. Thus, a user that wants to authenticate to a realm, can contact any authserver in that realm.

If the realm directive does NOT appear in this file, the authserver will not join any realm. This behavior is the default. If the realm directive does appear, name cannot be empty.

NOTE: Changing an authserver's realm after users have already registered using SRP requires all users to update their authentication data because the realm is bound into the stored SRP information. Specifically, each user will need to run

sfskey edit -o sfskey.priv username@authserver
sfskey update -a authserver:HOSTID sfskey.priv sfskey.priv
rm sfskey.priv

If the user has a local copy of his private key, in ~/.sfs/identity for example, only the second step is necessary. Also, if the user can login to the authserver, he can replace authserver:HOSTID with - (the minus sign). Thus, in the simplest case, the user could simply run

sfskey update -a - ~/.sfs/identity

Certpath dir [dir ...]
Specify a certification path to return to the client as a result of an "sfskey login" command; this list of directories will become the arguments to a dirsearch certprog. That is, for a certpath "dir1 dir2" the client will add a certprog "dirsearch dir1 dir2" to the user's agent. The certification path will be tagged with a prefix equal to the authserver's realm (see above).

NOTE: The certpath directive only makes sense if the authserver is part of a realm. The certpath will be ignored if the realm directive isn't specified.

There are three ways to specify a certpath directory:

certpath //dir1 /dir2 sfs.host.domain:HOSTID/dir2

which can also be written

certpath //dir1
certpath /dir2
certpath sfs.host.domain:HOSTID/dir2

A directory starting with two slashes ("//") is considered relative to the client machine's root ("/"). A directory starting with one slash ("/") is relative to the authserver's self-certifying pathname (the authserver performs the substitution before is sends the dir). The third form is a fully specified directory on SFS.

The default certpath is empty.