The rootd/proofd daemon
servers accept 6 methods of authentication, listed in Table 1, together with their internal codes and short
names.
Method 5 (rfio) is provided for fast access when security is not an issue.
Method 0 can be 'secured' by using a session public key, automatically
generated, which allows to avoid direct exchange of passwords; since this
may slow down the process, it can be switched of if not needed.
Table 1: authentication methods
available
| Method |
Code |
Short Name |
in .rootrc |
Secure |
| (user,password) (user,password) SRP Kerberos V Globus GSSAPI SSH (uid,gid) |
0 1 2 3 4 5 |
usrpwd srp krb5 globus ssh uidgid |
UsrPwd SRP Krb5 Globus Ssh UidGid |
Yes Yes Yes Yes Yes No |
A specific method can be requested via the .rootrc
family files (in order of priority: $HOME/.rootrc, /etc/root/system.rootrc
and $ROOTSYS/etc/system.rootrc),
the file $HOME/.rootauthrc (superseeded
by the variable ROOTAUTHRC, if defined), or during the root session as explained
below.
Connecting to a rootd/proofd daemon
requires a user account on the
remote machine.
For Kerberos, the username
is derived from the client principal,
assumed in the form user@MY.DOMA.IN.
For Globus, the
username is the one defined in gridmap
on the remote host.
To access anonymous file servers,
(see here for setup
instructions ), e.g. fserv, use '~fserv/' in front
of the file name, e.g.
TFile *f = TFile::Open("root://host.doma.in/~fserv/TheFile.root","read")
which logs into the default remote user account from where the wanted
file is reached.
If the remote host administrator has allowed direct access to fserv
(see Controlling Access), then
a direct login onto the anonymous file server is possible via
TFile *f = TFile::Open("root://fserv@host.doma.in/TheFile.root","read")
reducing the authentication process to a simple check that 'fserv'
exists on the remote host (password in the form user@client_host
is automatically generated by the
client class); this may provide faster access if security is not an issue.
When your system uses shadow passwords
you have to compile rootd/proofd with -DR__SHADOWPW (see
$ROOTSYS/rootd/Module.mk).
Since shadow passwords
can only be accessed while being superuser (root) this works only when
servers are started via (x)inetd. This is inconvenient when you
want to run rootd/proofd
as private user. To solve this problem you should create a file $HOME/.rootdpass
containing your encrypted password. If this file exists
its password is used for authentication. This method overrides shadow
password check for method 0. To create an encrypted password use the perl script provided in $ROOTSYS/proof/utils/crypt like:
$ROOTSYS/proof/utils/crypt "mypasswd" > $HOME/.rootdpass chmod 600 $HOME/.rootdpasswhere "mypasswd" should be your password (omit the quotes).
If ROOT was compiled with AFS suppor, on machines with AFS rootd/proofd will obtain an AFS token. To rebuild rootd/proofd with AFS support see the install instructions.
Providing Credentials
If valid credentials are not found during an authentication attempt,
the relevant information is asked for via command line prompt.
Alternative ways to provide credential information depend on the method:
UsrPwd, SRP: three ways
are provided:
# Setting it globally via the static TAuthenticate functions
TAuthenticate::SetGlobalUser() and
TAuthenticate::SetGlobalPasswd()
# Via the ~/.rootnetrc file. This
file has the same format as the ~/.netrc
file as used by ftp, with in addition the keyword secure instead
of machine to tell the system that
that line should be used for secure authentication in case of SRP or
protocols roots/proofs.
# Via the ~/.netrc file (same format
and file as used by ftp), which will be tried after ~/.rootnetrc has been tried.
Kerberos, Globus:
# creating valid tokens (kerberos) with kinit or proxies (Globus) with grid-proxy-init before running the root session;
the duration validity
of these credentials is finite and can be set at initialization time ( kinit -l 30h or grid-proxy-init
-H 30:00 to get a ticket for 30 hours)
SSH:
# creating the $HOME/.ssh/.identity,
$HOME/.ssh/.id_rsa or $HOME/.ssh/.id_dsa private keys files (with
ssh-keygen) and copying the
related public keys in $HOME/.ssh/authorized_keys
on the remote host.
Upon request of access, rootd/proofd build a list of secure methods
available locally; the list contains UsrPwd and, according to the compilation
flags,
SRP, Kerberos, Globus and SSH; for the latter, the running status of the
'sshd' daemon is checked. By default the two servers accept authentications
only via the methods in such a list. However, the server administrator
can restrict access via the default secure methods or grant access via some
of
the insecure methods; these actions can be (host,user) specific and
are defined in etc/rpdauth.allow (see example and explanation
for this file in
$ROOTSYS/etc/rpdauth.allow
).
Negotiation
Simple negotiation is supported in the following way. The client sends
the preferred method (the first one in the list, see below) to the server;
if this is among the methods
accepted by the server (not necessarily the one preferred by the server)
authentication is attempted. In the case the attempt is unsuccessful, the
server sends
back the list of the remaining methods accepted (if any); the client
compares the server list with its own list of remaining methods and makes
a new attempt if
the overlap of the two lists is not empty; and so on.
The way the server defines the (host and user specific) list of
accepted methods is described in the previous
session.
Slave/Data servers authentication during a PROOF session
During a PROOF session there is the potential problem of Master/Slave or
Slave/Data_Server authentication. For slaves, the list of methods to be tried
is specified
in the proof/etc/proof.conf file as a list of methods short
names. However, before build the corresponding entry in THostAuth,
TProof checks that the method can
be applied, i.e. that there valid credentials. The way these are
trasmitted depends on the method to be used and on the method used by the
Client to authenticate vs the
Master.
UsrPwd: to authenticate 'usrpwd' to slaves,
the master needs the relevant entry in the .netrc or .rootnetrc files; however,
if the client/master authentication was also
'usrpwd', the password is already present on the master process and is used
for later usrpwd authentications.
SRP: to authenticate 'SRP' to slaves, the master needs the relevant entry in the .netrc or .rootnetrc files.
Krb5: to authenticate
'Kerberos' to slaves, the master needs the kerberos tokens; these must be
initialized by hand on the
master, since for the time being, ticket
forwarding has not been implemented.
Globus: to authenticate 'Globus'
to slaves, the master needs globus credentials; this is possible (and automatic)
only if the client/master authentication was also
'globus'.
SSH: to authenticate 'SSH' to slaves, the master needs the relevant private key files in $HOME/.ssh (on the master).
UidGid: to authenticate 'UidGid' to slaves,
the user must have the same (uid,gid) on master and slaves.
Negotiation is active also between master and slaves, so it is a
good habit to ask for rfio first to accelerate as possible the authentication
process.
The method actually used is listed by gProof->Print().
If the slaves need to access data servers
which are not part of the proof cluster, the login info vis-a-vis
of these may be specified with the proofdserv
card in the
.rootauthrc files; the collected information
is then trasmitted to all the active slaves upon creation.
The authentication related entries in the .rootrc family of files define directives applying to all remote host and all remote accounts. The available directives are the following:
General switchings
Rootd.Authentication
code
Prootd.Authentication
code
These variables specify the default
method to be attempted for remote authentication for rootd and
proofd respectively; code is
the internal code given in Table 1;
these directives superseed the defaults
('ssh' for normal users and 'clear' for anonymous users).
method.Login directives
These directives specify the default login for the method:
UsrPwd.Login,
SRP.Login, Ssh.Login, UidGid.Login
UserName
(eg: qwerty)
Krb5.Login
Principal
(eg. qwerty@THIS.DOM.AIN )
Globus.Login
cd:dir_with_my_certs cf:my_cert_file
kf:my_key_file ad:dir_with_CA_certs
(eg: cd:SimpleCA/asdfgh )
method.LoginPrompt directives
These directives specify whether root
should prompt you for the login (with default the login specified via method.Login;
possible values are 0 or no for no prompt,
1 or yes to have the
prompt; valid examples:
UsrPwd.LoginPrompt
0
Krb5.LoginPrompt
1
Globus.LoginPrompt
no
Ssh.LoginPrompt
yes
Default is no
prompt.
For anonymous
'clear' login, 'Login.Prompt no' implies automatic
generation of the password in the form user@local_host_fqdn,
where user is obtained from
the environment variable USER or from
' getpwuid(getuid())->pw_name '.
method.ReUse directives
These directives specify whether root
reuse valid authentication once established; possible values are 0
or no for OFF, 1 or yes for ON.
When this option is active, the client
generates a session RSA key pair and transmits the public key to the server;
the server generates a session token
which can be used by the client for
later access to the server. This facility is implemented for all methods
except UidGid (for which there would be no advantage);
it is switched
ON by default for UsrPwd,Globus and Ssh,
since it allows to speed up significantly repeated access to the same server.
For SRP and Krb5
it is implemented but switched OFF by default,
since it does not improve on authentication time (especially for
Krb5).
UsrPwd.ReUse:
yes
SRP.ReUse:
no
Krb5.ReUse:
0
Globus.ReUse:
yes
Ssh.ReUse:
1
Other directives
UsrPwd
To secure password exchange
set (this is the default)
UsrPwd.Crypt
1
A session key pair
is generated and used to encrypt the password hash to be communicated to
the server. Default is 1.
Globus
To change the duration in hours of globus credentials (default is 12) use
Globus.ProxyDuration hours
To change the number of bits in the key (default 1024)
Globus.ProxyKeyBits bits
where bits is 512 or 1024 or 2048 or 4096
Ssh
To change the path with the 'ssh' excutable
Ssh.ExecDir sshexecdir
(the executable will then be sshexecdir/ssh)
The $HOME/.rootauthrc file (or the absolute path file name
in ROOTAUTHRC, if defined) allow to specifiy host and user specific instructions;
an example and explanations for
this file can be found in $ROOTSYS/etc/example.rootauthrc.
The information read is used to instantiate THostAuth objects; these can
be modified during the root session as
explained in the next
session.
This file allows to define host specific methods and defaults for the info (username, certificates, ...) to be used. The information specified here superseeds the one found in .rootrc .
Format:
- lines starting with '#' are comment lines
- lines of the form 'include <file>'
allow to include other files of this kind which are expanded exactly at
the point where the 'include' appears.
- lines of the form
proofdserv <host1>[:<user1>][:<method1>]
<host2>[:<user2>][:<method2>] \
<host3>[:<user3>][:<method3>] ...
are active only for proof sessions and
specify the list of hosts for which the authentication info should be transmitted
to the master of the proof cluster; these directives are useful, for example,
in
the case of data servers external to the
proof cluster that you may want to access via a given 'user' and
a given authentication 'method'; 'user' and 'method'
are not mandatory; for each <host>
(and user, method) specified with 'proofdserv'
all the information that can be collected from the rest of the .rootauthrc
file is sent to the master. This line can be continued with '\' .
- remaining valid lines are of the form
<host> [user <username>] <key> <info>
where <host> is the host(s) identifier
(see below), <key> is an option key and <info>
is the relevant info whose format depends on <key>; 'user'
indicates the username to whom the information applies;
if absent, the info applies to all users.
<host>:
- hosts can specified
either with their FQDN (eg, pcepsft43.cern.ch) or their IP address (eg
137.138.99.73)
- if <host>=default
the following <key> <info> applies to all hosts, unless
host-specific entries are found downstream.
- The '*' character
can be used in the first field of the name to indicate a set of machines,
eg pcepsft*.cern.ch applies to all 'pcepsft' machines in the domain
'cern.ch'
(To
indicate all 'lxplus' machines you should use 'lxplus*.cern.ch' because
internally the generic lxplus machine has a real name of the form lxplusnnn.cern.ch)
- A whole domain
can be indicated by its name, with at least two non null fields, eg 'cern.ch'
or '.cern.ch' ; '.ch' is not accepted
- Subsets of the
IP address can also be used to indicate a set of machines; however, it is
mandatory to end the subset with a '.', eg '137.138.' is an alternative
way to indicate the 'cern.ch'
domain,
but '137.138' is invalid because ambiguous
<key> <info>:
- valid keys are
'list' and 'method';
- if <key>=list, <info> contains
the list of codes or short names for methods (see Table 1) that can/should be tried for authentication
wrt to <host>, in order of preference.
Example
of a valid 'list' line:
default
list 4
lxplus*.cern.ch list
ssh 3 krb5
The first line defines as default method SSH; this is equivalent of setting
Rootd.Authentication 4
Proofd.Authentication
4
in the .rootrc file.
The second line adds Globus and Kerberos as available methods for authentication wrt lxplus machines (in addition to SSH): SSH the preferred one, Kerberos the last option.
Having a line 'list' for a host is not mandatory: methods can also be defined directly via 'method' lines (see below); in such a case the first 'method' line will define the preferredmethod and so on.
- if <key>=method, <info> contains
+ a method code
--> mandatory, must be in the valid range
+ a prompt flag
--> optional, identified by the key 'pt:', eg. pt:yes
[values: 'yes' or 1, 'no' or '0' ]
+ a reuse flag
--> optional, identified by the key 'ru:', eg. ru:no
[values: 'yes' or 1, 'no' or '0']
+ some relevant information for authentication (optional, see below)
The
'prompt' flag defines whether the user should be prompted for the
relevant authentication details each time an authentication with the corresponding
method is attempted.Default is 'yes', superseeded by
the
related entry in '.rootrc' .
The
'reuse' flag determines if a successful authentication will be later
re-used without prompting (eg when the user tries to access the same host
with same method during the same session: this allows to
speed
up operation in case of multiple access); default is 'yes'. No additional
info is needed by method 5 (Rfio): this method sends to the remote host
the (uid,gid) of the current process; 'reuse' will be af no
advantage
and 'prompt' is not allowed for security reasons.
The
format for the default authentication information depends on the
method:
Method Format info
(user,password)
us:<username>
SRP
us:<username>
Kerberos
us:<principal>
Globus
cd:<user_certkey_dir> cf:<usercert_file> kf:<userkey_file>
ad:<authorities_dir>
SSH
us:<username>
(uid,gid)
us:<username>
The
keys for Globus allow to specify only partial changes of the defaults: 'cd'
defines the directory containing the user certificate and private key files;
'cf' defines the user certificate file
'kf'
defines the user private key file 'ad' defines the directory containing credentials
for recognized Certificate Authorities (the CA signing the remote host certificate
must have an entry here)
All
these files and directories can be specified as absolute paths (starting
with '/') or as relative to the getenv("HOME") directory (starting with
'~/') or relative to the local '.globus' directory.
Defaults
are: cd:~/.globus cf:usercert.pem kf:userkey.pem
ad:/etc/grid-security/certificates
NB: for all the mentioned keys, there should be NO space between the key and the value, eg 'us: qwerty' will result in <username>=""
Example of a valid 'method' lines:
default method ssh pt:yes us:qwerty
default method 3 pt:0
default user asdfgh
method clear pt:1
ru:no
lxplus*.cern.ch method 3 pt:no ad:certificates
pcepsft43.cern.ch user poiuytmethodglobus pt:no cd:~/CA/HubCA/poiuyt ad:certificates
The
first line specifies that when a SSH authentication is attempted, the user
will be prompted for the remote username, with 'qwerty' as default.
The
second line states that for Globus the user will not be prompted and the
credentials and related files will be looked for in the default places.
The
third line specifies that, for clear authentication, user 'asdfgh'
will get a prompt with default username 'asdfgh' and that a successful
authentication will not be reused
The
fourth line tells that for Globus wrt lxplus, the user will still not be
prompted, but the credentials for the CA signing the remote certificate
will be looked for in ~/.globus/certificates
The
fifth line tells that for Globus authentication on pcepsft43 of user 'poiuyt',
the usercert.pem and userkey.pem files are looked for
in directory ~/CA/HubCA/poiuyt, and the credentials for the CA
signing
the
remote certificate in ~/.globus/certificates
Modifying/Adding authentication info during the session
Remote authentication in root is controlled by the TAuthenticate
class; TNetFile, TFTP and TSlave create a TAuthenticate object before attempting
authentication by
means of the Authenticate() method.
Authentication is (host,user) specific. The dedicated class THostAuth
contains the information for a specific (host,user):
- remote host FQDN
- user name
- number of available methods
n
- method internal codes (dimension
n)
- login info for each method
(dimension n)
- list of established authentication
The available methods are listed in order of preference: the first
one is the one preferred, the others are tried in turn upon failure of the
previous one, and if accepted
by the remote daemon (see Negotiation above). THostAuth objects
are instantiated by TAuthenticate upon creation based on the information
found in the files
mentioned above.
A set of methods are available in the TAuthenticate
and THostAuth classes to display/modify/create THostAuth classes:
void TAuthenticate::PrintHostAuth()
Prints the contant of the instantiated THostAuth objects
Example:
root [1] TAuthenticate::PrintHostAuth()
Info in <THostAuth::Print>: +------------------------------------------------------------------+
Info in <THostAuth::Print>: + Host:pcepsft43.cern.ch - User:ganis
- # of available methods:5
Info in <THostAuth::Print>: + Method: 3 Details:pt:no cd:~/.globus
cf:usercert.pem kf:userkey.pem ad:certificates
Info in <THostAuth::Print>: + Method: 4 Details:pt:no ru:1 us:ganis
Info in THostAuth::Print: + Method: 0 Details:pt:no us:ganis
Info in <THostAuth::Print>: + Method: 1 Details:pt:no ru:1 us:ganis
Info in THostAuth::Print: + Method: 5 Details:pt:yes us:ganis
Info in <THostAuth::Print>: +------------------------------------------------------------------+
Info in <THostAuth::PrintEstablished>: +------------------------------------------------------------------+
Info in <THostAuth::PrintEstablished>: + Host:pcepsft43.cern.ch -
Number of Established Authentications: 1
Info in <TAuthDetails::PrintEstblshd>: + Method:1 OffSet:278 Login:ganis
Prompt:0 ReUse:1
Info in <TAuthDetails::PrintEstblshd>: + Details:pt:0 ru:1 us:ganis
Info in <THostAuth::PrintEstablished>: +------------------------------------------------------------------+
root [2]
The method THostAuth::PrintEstablished is also called, displaying the relevant
info about successful authentications saved in TAuthDetails
(see below for details about TAuthDetails).
THostAuth
*TAuthenticate::GetHostAuth("host_fqdn","user")
Returns a pointer to the THostAuth object pertaining to (host,user) if it
exist, NULL otherwise.
Example:
root [2] THostAuth *ha = TAuthenticate::GetHostAuth("pcepsft43.cern.ch","ganis")
root [3] printf("ha: 0x%x\n",(int)ha);
ha: 0x88df970
root [4] THostAuth *ha = TAuthenticate::GetHostAuth("der.mit.ow","scruno")
root [5] printf("ha: 0x%x\n",(int)ha);
ha: 0x0
root [6]
void
TAuthenticate::ReadAuthRc("host_fqdn","user")
Loads information about (host,user) from .rooauthrc or from the defaults
in .rootrc
void
TAuthenticate::RemoveHostAuth(THostAuth *ha)
Removes and destroys the THostAuth object pointed by ha from the static
list in TAuthenticate
void
THostAuth::Print()
Prints the information contained in this THostAuth object
Example:
root [7] THostAuth *ha = TAuthenticate::GetHostAuth("pcepsft43.cern.ch","ganis")
root [8] ha->Print()
Info in <THostAuth::Print>: +------------------------------------------------------------------+
Info in <THostAuth::Print>: + Host:pcepsft43.cern.ch - User:ganis
- # of available methods:5
Info in <THostAuth::Print>: + Method: 3 Details:pt:no cd:~/.globus
cf:usercert.pem kf:userkey.pem ad:certificates
Info in <THostAuth::Print>: + Method: 4 Details:pt:no ru:1 us:ganis
Info in <THostAuth::Print>: + Method: 1 Details:pt:no ru:1 us:ganis
Info in <THostAuth::Print>: + Method: 5 Details:pt:yes us:ganis
Info in <THostAuth::Print>: +------------------------------------------------------------------+
root [9]
void
THostAuth::AddMethod(code,login_inf)
Add a new method (internal code , login information login_info) at the end
of the list of available methods
Example (with respect to above):
root [9] ha->AddMethod(0,"no us:ganis")
root [10] ha->Print()
Info in <THostAuth::Print>: +------------------------------------------------------------------+
Info in <THostAuth::Print>: + Host:pcepsft43.cern.ch - User:ganis
- # of available methods:4
Info in <THostAuth::Print>: + Method: 3 Details:pt:no cd:~/.globus
cf:usercert.pem kf:userkey.pem ad:certificates
Info in <THostAuth::Print>: + Method: 4 Details:pt:no ru:1 us:ganis
Info inTHostAuth::Print: + Method: 1 Details:pt:no ru:1 us:ganis
Info in <THostAuth::Print>: + Method: 5 Details:pt:yes us:ganis Info
in THostAuth::Print: + Method: 0 Details:pt:no us:ganis
Info in <THostAuth::Print>: +------------------------------------------------------------------+
root [11]
void
THostAuth::RemoveMethod(code)
Removes method with internal code from the list of available methods
Example (with respect to above):
root [9] ha->RemoveMethod(5)
root [10] ha->Print()
Info in <THostAuth::Print>: +------------------------------------------------------------------+
Info in <THostAuth::Print>: + Host:pcepsft43.cern.ch - User:ganis
- # of available methods:4
Info in <THostAuth::Print>: + Method: 3 Details:pt:no cd:~/.globus
cf:usercert.pem kf:userkey.pem ad:certificates
Info in <THostAuth::Print>: + Method: 4 Details:pt:no ru:1 us:ganis
Info in <THostAuth::Print>: + Method: 1 Details:pt:no ru:1 us:ganis
Info in <THostAuth::Print>: + Method: 0 Details:pt:no us:ganis
Info in <THostAuth::Print>: +------------------------------------------------------------------+
root [11]
void
THostAuth::SetDetails(code,login_inf)
Changes login info for method with internal code to login_info; if it does
not exist, add a this as new method.
Example (with respect to above):
root [11] ha->SetDetails(4,"pt:no ru:1 us:gganis")
root [12] ha->Print()
Info in <THostAuth::Print>: +------------------------------------------------------------------+
Info in <THostAuth::Print>: + Host:pcepsft43.cern.ch - User:ganis
- # of available methods:4
Info in <THostAuth::Print>: + Method: 3 Details:pt:no cd:~/.globus
cf:usercert.pem kf:userkey.pem ad:certificates
Info in <THostAuth::Print>: + Method: 4 Details:pt:no ru:1 us:gganis
Info in THostAuth::Print: + Method: 1 Details:pt:no ru:1 us:ganis
Info in <THostAuth::Print>: + Method: 0 Details:pt:no us:ganis
Info in <THostAuth::Print>: +------------------------------------------------------------------+
root [13]
void
THostAuth::SetFirst(code)
Set method with internal code as the preferred one, if it exists.
Example (with respect to above):
root [13] ha->SetFirst(1)
root [14] ha->Print()
Info in <THostAuth::Print>: +------------------------------------------------------------------+
Info in <THostAuth::Print>: + Host:pcepsft43.cern.ch - User:ganis
- # of available methods:4
Info in <THostAuth::Print>: + Method: 1 Details:pt:no ru:1 us:ganis
Info in <THostAuth::Print>: + Method: 3 Details:pt:no cd:~/.globus
cf:usercert.pem kf:userkey.pem ad:certificates
Info in <THostAuth::Print>: + Method: 4 Details:pt:no ru:1 us:gganis
Info in <THostAuth::Print>: + Method: 0 Details:pt:no us:ganis
Info in <THostAuth::Print>: +------------------------------------------------------------------+
root [15]
void
THostAuth::SetFirst(code,login_inf)
Set method with internal code as the preferred one, and changes the login
information to login_inf. If it does not exist, add a new method in
first position.
void
THostAuth::ReOrder(nmet,meths)
Reorder the list of the available methods in such a way that the first nmet
methods are the ones listed in meths[nmet].
The class TAuthDetails contains
the relevant details about a successful authentication:
- remote host FQDN
- remote port number
- remote service flag (1= rootd,
2= proofd)
- authentication method used
- offset in remote authentication
tab file
- remote login name
- information used to authenticate
(user, principal, location of certificate/key files, ...)
- a flag specifying whether this
authentication can be reused (1 = yes, 0 = no)
- token uniquely identifying this
authentication
If ReUse is active this information can be used to speed up access
to the same (host,user) entity during the same session.
Each THostAuth contains a list of TAuthDetails objects pertaining to {host,user}.
See $ROOTSYS/net/inc/TAuthDetails.h
for details.
Compilation/Installation details about the different secure methods
To build rootd with SRP you have to do the following:
TFile *f1 = new TNetFile("roots://host/file1.root");
TFile *f2 = TFile::Open("roots://remote/file2.root");
The system will dynamically load libSRPAuth.so if it exists
and SRP will be used for the authentication. Note that other rootd
traffic is not encrypted.
Several binary distributions already come with everything needed to
run SRP (check for the existence of, for example, $ROOTSYS/lib/libSRPAuth.so).
If your ROOT has been built with kerberos support and you specify the rootk protocol to TNetFile, ROOT will try to authenticate you to the remote host using kerberos. If the server does not support kerberos authentication, or if the authentication fails, ROOT falls back to using the other authentication methods.
To build rootd/proofd with kerberos authentication you have to do the following:
[root@cdflx13 /]# klist -k
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
2 rootd/cdflx13.lbl.gov@MSTADT.LBL.GOV
[root@cdflx13 /]# grep rootd /etc/inetd.conf
rootd stream tcp nowait root /home/jmuelmen/root/bin/rootd rootd
-i
Meanwhile, on the client host (brooklyn-bridge), things could look like this:
[jmuelmen@brooklyn-bridge jmuelmen]$ kinit
Password for jmuelmen@MSTADT.LBL.GOV:
[jmuelmen@brooklyn-bridge jmuelmen]$ klist
Ticket cache: FILE:/tmp/krb5cc_1001
Default principal: jmuelmen@MSTADT.LBL.GOV
Valid starting Expires
Service principal
03/16/02 02:34:47 03/16/02 12:34:47 krbtgt/MSTADT.LBL.GOV@MSTADT.LBL.GOV
The client can then get a ROOT file from the server without any passwords being exchanged:
root [1] TFile *f = TFile::Open("rootk://cdflx13.lbl.gov/mu.root")
Remote protocol version is 5, kerberos supported.
Sendauth succeeded; authenticated as jmuelmen@MSTADT.LBL.GOV
(class TFile*)0x86eb688
root [2]
Globus Authentication has been tested for the moment only on Linux.
To build rootd/proofd with Globus authentication one needs:
The host running the rootd/proofd server must have a host certificate
from the same CA issuing your certificate. This certificate is looked for
in /etc/grid-security/hostcert.pem;
additional or non-standard locations can be specified by means of the /etc/root/hostcert.conf file; see README.GLOBUS
for more details.
By default the rootd/proofd servers look for the host certificate; if running
from a user account, the user certificate and key files should be specified
in hostcert.conf,
and the Globus proxies initizialized manually; however, this may not work
if some files are not accessible by the user; the error message may give a
hint about the
origine of the problem.
On the client side, Globus authentication can be requested one of the following ways:
1) set
Rootd.Authentication
3
in your .rootrc file. Certficate and key files are looked for in the $HOME/.globus directory under the names usercert.pem and userkey.pem. This default can be changed with Globus.Login .
2) set
host.my.domain user qwerty method 3 ad:certificates
in your .rootauthrc file. In this case you will attempt
to login as qwerty on remote host
host.my.domain using Globus and standard
location for the user files needed, while certificates for the known CA
are looked for in
$HOME/.globus/certificates.
3) inside a root session,
- create a new THostAuth class:
root[n] THostAuth *ha = new THostAuth("host.my.domain","qwerty",3,"ad:certificates");
- add it to the static list in TAuthenticate:
root[n+1] TAuthenticate::GetAuthInfo().Add(ha)
- or add/modify a method using the methods presented above.
Trying to access a remote file should give this on the client side (assuming globus credentials have not been initialized before):
root [1] TFile *f1 = TFile::Open("root://<remote_FQDN>/test.root","read")
Your identity: /O=Grid/OU=GlobusTest/OU=simpleCA-arthux.cern.ch/OU=cern.ch/CN=qwerty
Enter GRID pass phrase for this identity:
Creating proxy ....................... Done
Your proxy is valid until Wed May 28 02:46:12 2003
root [2]
The first authentication to a (remotehost,username) entity may be perceived as slow; this is because a lot of exchanges are need to establish the security context; however, the security context is kept until is valid, so subsequent access to the same entity will be much faster (if this is not so, make sure that you do not have set the 'reuse' flag to '0' or 'no'; see above).
In a PROOF cluster, if the master requires Globus credentials for authentication to slaves, these are authomatically transmitted using a shared memory.
There is no need to build special modules for SSH authentication;
you need, however, to specify the dir path of the 'ssh' executable
if not standard ( /usr/bin/ssh or /usr/local/bin ) with
--with-ssh-dir=<ssh_path_dir>. On the server side, 'rootd'
and 'proofd' will test the presence of the 'sshd' daemon
on port 22 (or on the one specified by option -s; see 'rootd.cxx'/'proofd.cxx'
headers).