Authentication options

Authentication method




External authentication

  • A framework that enables you to integrate LSF with any third-party authentication product—such as Kerberos or DCE Security Services—to authenticate users, hosts, and daemons. This feature provides a secure transfer of data within the authentication data stream between LSF clients and servers. Using external authentication, you can customize LSF to meet the security requirements of your site.


  • LSF uses the default eauth executable located in LSF_SERVERDIR. The default executable provides an example of how the eauth protocol works. You should write your own eauth executable to meet the security requirements of your cluster. For a detailed description of the external authentication feature and how to configure it, see External Authentication.

Identification daemon (identd)

  • Authentication using the identd daemon available in the public domain.


  • LSF uses the identd daemon available in the public domain.

  • LSF supports both RFC 931 and RFC 1413 protocols.

Privileged ports (setuid)

  • User authentication between LSF clients and servers on UNIX hosts only. An LSF command or other executable configured as setuid uses a reserved (privileged) port number (1-1024) to contact an LSF server. The LSF server accepts requests received on a privileged port as coming from the root user and then runs the LSF command or other executable using the real user account of the user who issued the command.

LSF_AUTH not defined

  • For UNIX hosts only, LSF clients (API functions) use reserved ports 1-1024 to communicate with LSF servers.

  • The number of user accounts that can connect concurrently to remote hosts is limited by the number of available privileged ports.

  • LSF_AUTH must be deleted or commented out and LSF commands must be installed as setuid programs owned by root.

UNIX user and host authentication

The primary LSF administrator can configure additional authentication for UNIX users and hosts by defining the parameter LSF_USE_HOSTEQUIV in the lsf.conf file. With LSF_USE_HOSTEQUIV defined, mbatchd on the master host and RES on the remote host call the ruserok(3) function to verify that the originating host is listed in the /etc/hosts.equiv file and that the host and user account are listed in the $HOME/.rhosts file. Include the name of the local host in both files. This additional level of authentication works in conjunction with eauth, privileged ports (setuid), or identd authentication.


Using the /etc/hosts.equiv and $HOME/.rhosts files grants permission to use the rlogin and rsh commands without requiring a password.


SSH is a network protocol that provides confidentiality and integrity of data using a secure channel between two networked devices. Use SSH to secure communication between submission, execution, and display hosts.

A frequently used option is to submit jobs with SSH X11 forwarding (bsub -XF), which allows a user to log into an X-Server client, access the submission host through the client, and run an interactive X-Window job, all through SSH.

Strict checking protocol in an untrusted environment

To improve security in an untrusted environment, the primary LSF administrator can enable the use of a strict checking communications protocol. When you define LSF_STRICT_CHECKING in lsf.conf, LSF authenticates messages passed between LSF daemons and between LSF commands and daemons. This type of authentication is not required in a secure environment, such as when your cluster is protected by a firewall.

You must shut down the cluster before adding or deleting the LSF_STRICT_CHECKING parameter.

Authentication failure

If authentication fails (the user’s identity cannot be verified), LSF displays the following error message after a user issues an LSF command:
User permission denied
This error has several possible causes depending on the authentication method used.

Authentication method

Possible cause of failure


  • External authentication failed


  • The identification daemon is not available on the local or submitting host


  • The LSF applications are not installed setuid

  • The NFS directory is mounted with the nosuid option


  • The client (local) host is not found in either the /etc/hosts.equiv or the $HOME/.rhosts file on the master or remote host