Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
Applies to SUSE Linux Enterprise High Availability Extension 15 SP2

D Running Cluster Reports Without root Access Edit source

All cluster nodes must be able to access each other via SSH. Tools like crm report (for troubleshooting) and Hawk2's History Explorer require passwordless SSH access between the nodes, otherwise they can only collect data from the current node.

If passwordless SSH root access does not comply with regulatory requirements, you can use a work-around for running cluster reports. It consists of the following basic steps:

  1. Creating a dedicated local user account (for running crm report).

  2. Configuring passwordless SSH access for that user account, ideally by using a non-standard SSH port.

  3. Configuring sudo for that user.

  4. Running crm report as that user.

By default when crm report is run, it attempts to log in to remote nodes first as root, then as user hacluster. However, if your local security policy prevents root login using SSH, the script execution will fail on all remote nodes. Even attempting to run the script as user hacluster will fail because this is a service account, and its shell is set to /bin/false, which prevents login. Creating a dedicated local user is the only option to successfully run the crm report script on all nodes in the High Availability cluster.

D.1 Creating a Local User Account Edit source

In the following example, we will create a local user named hareport from command line. The password can be anything that meets your security requirements. Alternatively, you can create the user account and set the password with YaST.

Procedure D.1: Creating a Dedicated User Account for Running Cluster Reports
  1. Start a shell and create a user hareport with a home directory /home/hareport :

    root # useradd -m -d /home/hareport -c "HA Report" hareport
  2. Set a password for the user:

    root # passwd hareport
  3. When prompted, enter and re-enter a password for the user.

Important: Same User Is Required On Each Cluster Node

To create the same user account on all nodes, repeat the steps above on each cluster node.

D.2 Configuring a Passwordless SSH Account Edit source

Procedure D.2: Configuring the SSH Daemon for a Non-Standard Port

By default, the SSH daemon and the SSH client talk and listen on port 22. If your network security guidelines require the default SSH port to be changed to an alternate high numbered port, you need to modify the daemon's configuration file /etc/ssh/sshd_config.

  1. To modify the default port, search the file for the Port line, uncomment it and edit it according to your wishes. For example, set it to:

    Port 5022
  2. If your organization does not permit the root user to access other servers, search the file for the PermitRootLogin entry, uncomment it and set it to no:

    PermitRootLogin no
  3. Alternatively, add the respective lines to the end of the file by executing the following commands:

    root # echo “PermitRootLogin no” >> /etc/ssh/sshd_config
    root # echo “Port 5022” >> /etc/ssh/sshd_config
  4. After modifying /etc/ssh/sshd_config, restart the SSH daemon to make the new settings take effect:

    root # systemctl restart sshd
Important: Same Settings Are Required On Each Cluster Node

Repeat the SSH daemon configuration above on each cluster node.

Procedure D.3: Configuring the SSH Client for a Non-Standard Port

If the SSH port change is going to be made on all nodes in the cluster, it is useful to modify the SSH configuration file, /etc/ssh/sshd_config.

  1. To modify the default port, search the file for the Port line, uncomment it and edit it according to your wishes. For example, set it to:

    Port 5022
  2. Alternatively, add the respective line to the end of the file by executing the following commands:

    root # echo “Port 5022” >> /etc/ssh/ssh_config
Note: Settings Only Required on One Node

The SSH client configuration above is only needed on the node on which you want to run the cluster report.

Alternatively, you can use the -X option to run the crm report with a custom SSH port or even make crm report use your custom SSH port by default. For details, see Procedure D.5, “Generating a Cluster Report Using a Custom SSH Port”.

Procedure D.4: Configuring Shared SSH Keys

You can access other servers using SSH and not be asked for a password. While this may appear insecure at first sight, it is actually a very secure access method since the users can only access servers that their public key has been shared with. The shared key must be created as the user that will use the key.

  1. Log in to one of the nodes with the user account that you have created for running cluster reports (in our example above, the user account was hareport).

  2. Generate a new key:

    hareport > ssh-keygen –t rsa

    This command will generate a 2048 bit key by default. The default location for the key is ~/.ssh/. You are asked to set a passphrase on the key. However, do not enter a passphrase because for passwordless login there must not be a passphrase on the key.

  3. After the keys have been generated, copy the public key to each of the other nodes (including the node where you created the key):

    hareport > ssh-copy-id -i ~/.ssh/id_rsa.pub HOSTNAME_OR_IP

    In the command, you can either use the DNS name for each server, an alias, or the IP address. During the copy process you will be asked to accept the host key for each node, and you will need to provide the password for the hareport user account (this will be the only time you need to enter it).

  4. After the key is shared to all cluster nodes, test if you can log in as user hareport to the other nodes by using passwordless SSH:

    hareport > ssh HOSTNAME_OR_IP

    You should be automatically connected to the remote server without being asked to accept a certificate or enter a password.

Note: Settings Only Required on One Node

If you intend to run the cluster report from the same node each time, it is sufficient to execute the procedure above on this node only. Otherwise repeat the procedure on each node.

D.3 Configuring sudo Edit source

The sudo command allows a regular user to quickly become root and issue a command, with or without providing a password. Sudo access can be given to all root-level commands or to specific commands only. Sudo typically uses aliases to define the entire command string.

To configure sudo either use visudo (not vi) or YaST.

Warning: Do Not Use vi

For sudo configuration from command line, you must edit the sudoers file as root with visudo. Using any other editor may result in syntax or file permission errors that prevent sudo from running.

  1. Log in as root.

  2. To open the /etc/sudoers file, enter visudo.

  3. Look for the following categories: Host alias specification,User alias specification, Cmnd alias specification, and Runas alias specification.

  4. Add the following entries to the respective categories in /etc/sudoers:

    Host_Alias	CLUSTER = alice,bob,charlie 1
    User_Alias HA = hareport 2
    Cmnd_Alias HA_ALLOWED = /bin/su, /usr/sbin/crm report *3
    Runas_Alias R = root 4


    The host alias defines on which server (or range of servers) the sudo user has rights to issue commands. In the host alias you can use DNS names, or IP addresses, or specify an entire network range (for example, To limit the scope of access you should specify the host names for the cluster nodes only.


    The user alias allows you to add multiple local user accounts to a single alias. However, in this case you could avoid creating an alias since only one account is being used. In the example above, we added the hareport user which we have created for running cluster reports.


    The command alias defines which commands can be executed by the user. This is useful if you want to limit what the non-root user can access when using sudo. In this case the hareport user account will need access to the commands crm report and su.


    The runas alias specifies the account that the command will be run as. In this case root.

  5. Search for the following two lines:

    Defaults targetpw
    ALL     ALL=(ALL) ALL

    As they would conflict with the setup we want to create, disable them:

    #Defaults targetpw
    #ALL     ALL=(ALL) ALL
  6. Look for the User privilege specification.

  7. After having defined the aliases above, you can now add the following rule there:


    The NOPASSWORD option ensures that the user hareport can execute the cluster report without providing a password.

Important: Same sudo Configuration Is Required on Each Cluster Node

This sudo configuration must be made on all nodes in the cluster. No other changes are needed for sudo and no services need to be restarted.

D.4 Generating a Cluster Report Edit source

To run cluster reports with the settings you have configured above, you need to be logged in to one of the nodes as user hareport. To start a cluster report, use the crm report command. For example:

root # crm report -f 0:00 -n "alice bob charlie"

This command will extract all information since 0 am on the named nodes and create a *.tar.bz2 archive named pcmk-DATE.tar.bz2 in the current directory.

Procedure D.5: Generating a Cluster Report Using a Custom SSH Port
  1. When using a custom SSH port, use the -X with crm report to modify the client's SSH port. For example, if your custom SSH port is 5022, use the following command:

    root # crm report -X "-p 5022" [...]
  2. To set your custom SSH port permanently for crm report, start the interactive crm shell:

    crm options
  3. Enter the following:

    crm(live)options#  set core.report_tool_options "-X -oPort=5022"
Print this page