Node:sfsauthd_config
,
Next:sfs_users
,
Previous:sfsrwsd_config
,
Up:SFS configuration
sfsauthd_config
--User-authentication daemon configurationHostname name
Keyfile path
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
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
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
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
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
sfs_srp_params
. If the default file does not exist, serving
pre-generated SRP parameters is disabled.
Denyfile path
sfs_deny
. If the default file does not exist, we
assume an empty list.
Realm name
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 ...]
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.