Authentication determines the identity of the user or the user's program. For specifics, see, Strong Authentication at Fermilab


To protect against unauthorized access to Fermilab computers, the Computing Division has implemented Kerberos to provide what is known as strong authentication over the network. This means verifying the identities of networked users, client and servers without transmitting passwords over the network, and without requiring that the network itself be protected.

Certificates (often called "digital certificates") provide a way to verify a user's identity on a computer and/or over a computer network before allowing the user access to a protected web site, application, machine or other resources. Typical computer services that require certificate authentication by users include secure web sites, grid services, and email signing and encryption. For more information, see Certificates at Fermilab

Users have a single Fermilab user name, but there may be several kerberos principals derived from that username.

  • default principal
    Kerberos identities are based on a 'principal' which includes that name.
    Default principal: your-username@FNAL.GOV

Users get an active ticket for kerberos access with 'kinit'.
This ticket is a file on the local disk, usually in /tmp, see $KRB5CCNAME

  • cron principal
    Because cron jobs may need a ticket, and users are not there to type a password, there is a special kcron command to generate a special principal that looks like
    Default principal: your-username/cron/
  • root principal
    Some people need to access sensitive accounts, and may be authorized to have 'root' principals used only briefly.
    kinit your-username/root@FNAL.GOV
  • service principal
    There are special principals used mostly for automated processes to do remote system access. While these special principals have passwords, they are one-time passwords, since a keytab file is made for the principal and used via
    kinit -k -t <keytabfile>

    A 'service' principal has a special meaning. These are pincipals used for incoming services (i.e. host/node or nfs/node are service principals) for which service tickets must be acquired from the KDC.
  • .k5login access
    These cron and root principals are distinct from the default principals. If used for access to remote account, they need to be put in a user's .k5login access file.
  • KX509 proxies
    Access to Grid resources ( jobs, FTP transfers ) is via X509 certificates, which may be generated from the kerberos ticket. For job submission, this is handled by the kproxy script. For file access, users may need to run the 'getcert' command,

Logging in With Kerberos from a Non-Fermilab Computer

Users with non-Fermilab-managed computers need to add information to their .ssh/config or /etc/ssh_config or /etc/ssh/ssh_config (system dependent) files to forward the Kerberos tickets and forward X11 connections. This section may help with that. Users with Fermilab computers have this done by Fermilab.

Users must have the correct configuration for the /etc/krb5.conf file. The current Fermilab version of this file is available at: Note, if you access some other site besides Fermilab with Kerberos, you will need to merge the information in the above file with information for accessing those sites.

Users must have a valid kerberos ticket to access Fermilab computing at the time of an attempt to log into a Fermilab machine. The ticket is obtained by executing the following command at a terminal prompt:

$ kinit <principal>@FNAL.GOV

where <principal> is the user's kerberos principal, typically the username. (Not the User ID which is a number that identifies you on Linux/Unix/Mac system and is associated mainly with file ownership and permission If a user is attempting to access the repository from a non-Fermilab machine, the following lines must be in the user's .ssh/config:

Host *
ForwardAgent yes
ForwardX11 yes
ForwardX11Trusted yes
GSSAPIAuthentication yes
GSSAPIDelegateCredentials yes

In case of trouble when connecting via ssh (permission denied error) the reason can be in the OpenSSH client, the following client is compatible with Fermilab Kerberos authentification:
OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008

Depending on whether you are behind a NAT translation service, you may need "addressless" tickets. Experiment with the options -a and -A in kinit if you get a permission denied error when ssh'ing in.

It is possible to allow other users (or yourself just on another machine or with another Kerberos identity) to access your account via a .k5login file in your $HOME directory. See the earlier section on .k5login, and be sure to include your own username or you may be locked out.

Tip for Macintosh users, look at:
Also, if you're using MacPorts: It has been seen that MacPorts will install a version of Kerberos in /opt/local/bin that differs from the one that comes with Mac OS X and put it ahead of the sytem one in the user's path. This version will run kinit and give you tickets that look fine with klist, but which will not work when ssh'ing in to Fermilab computers. Use the Kerberos utilities that come with Mac OS X instead, in /usr/bin/.

OSG x509 Certificates

Users initially get an OSG cert in a browser, then save this on local disk using a passphrase. It is up to users to remember that passphrase.

The certificate is identified by the Common Name field, something like

Firstname Lastname 123

When it is renewed, this identity will be retained, avoiding the need to reregister with services.

For more information, see Certificates at Fermilab

Authentication with kcron

NOTE: In this example, we are using the interactive node
There is nothing special about this node, but one should be consistent with the node s/he chooses.
  • Initial setup do be done only once
  • Log as yourself to
  • Type the following commands and follow the inline instructions:
    Input Kerberos principal
    Input kerberos password
    source /grid/fermiapp/products/
    setup cigetcert
    cigetcert -vs
    voms-proxy-info -all
  • Get the subject of the output of the last command, it should look like:
    subject : /DC=org/DC=cilogon/C=US/O=Fermi National Accelerator Laboratory/OU=Robots/ Di Benedetto/CN=UID:vito
  • Open a SNOW request through "Scientific Computing"/"Create a New Scientific Computing Request", select NOvA Experiment and Category: ‘Batch Submission group’
    requesting the subject you got in the previous step, to be added to your voms user credentials (example request: RITM0318692).

How to use kcron to generate a proxy

  • Create a script with the following code and run it as a cronjob

source /cvmfs/
export KRB5CCNAME=/tmp/krb5cc_$(id -u)_kcron_$$
export X509_USER_PROXY=/tmp/x509up_u$(id -u)_kcron

setup cigetcert

echo -e "\ncleaning up existing proxy ...\n" 

echo -e "\ncigetcert ...\n" 
cigetcert -vs -o ${X509_USER_PROXY} && \
echo "got certigicate" || \
(exitcode=$?; echo -n "Error while getting certigicate\ncigetcert exited with exit code: $exitcode"; exit $exitcode)

echo -e "\nDisplay info about MyProxy credentials for user ${USER}...\n" 
myproxy-info -s -vd

echo -e "\nCreate the proxy for user ${USER} with role ${ROLE} ...\n" 
voms-proxy-init -noregen -rfc -voms fermilab:/fermilab/nova/Role=${ROLE} -valid 120:00 && \
echo "proxy created" || \
(exitcode=$?; echo -n "Error while creating proxy\nvoms-proxy-init exited with exit code: $exitcode"; exit $exitcode)

echo -e "\nDisplay proxyinfo ...\n" 
voms-proxy-info -all && \
echo "the proxy is OK" || \
(exitcode=$?; echo -n "Error while checking proxy\nvoms-proxy-info exited with exit code: $exitcode"; exit $exitcode)

echo "Updating the proxy" 
mv ${X509_USER_PROXY} /var/tmp/${USER}.${ROLE}.proxy
echo "Removing the cron principal" 
  • The fresh generated proxy is stored in /var/tmp/${USER}.${ROLE}.proxy (The final destination of the proxy must be on a local filesystem of the node).
  • The cronjob generate emails on the node where it runs, check those emails to verify if there is any issue in the process.
  • The default role is Analysis, it can be changed.
  • The proxy created is valid for 120 hours, i.e. 5 days (This is the maximum allowed).
  • The cronjob can be safely executed daily

How to use the proxy generated by the previous step

The previous step generate a proxy stored in /var/tmp/${USER}.${ROLE}.proxy
This proxy can be used by setting the environment variable X509_USER_PROXY to that path.

export ROLE=Analysis
export X509_USER_PROXY=/var/tmp/${USER}.${ROLE}.proxy

#here goes the code that uses the proxy.

If the tool you are using allows option to specify the proxy to use, you can provide the full path of the proxy.

NOTE: This proxy can be used only on the node where you have set up this procedure, in this example it is
This because the cron proncipal used to create the proxy is tied to a specific node.