Avoiding problems with SSH in a collective

Learn to avoid problems with SSH in a collective. Security problems usually relate to a user not having access to a resource because security is too restrictive. The SSH configuration option StrictModes protects public and private key files against the opposite problem, when security is too permissive. SSH provides secure communications between systems without password authentication, but SSH does not work if the permissions on certain directories and files are not strict enough.

About this task

The collective controller uses SSH to start and stop collective members. The Admin Center also uses SSH when you view and edit configuration files. Both of these functions fail if certain SSH directory and file permissions are too permissive.

For SSH support on z/OS®, see IBM® Ported Tools for z/OS: OpenSSHUser's Guide in the OpenSSH documentation.

What is SSH?
The collective scripts create the files that the controller uses to log in to member services that use public and private key authentication, which is the most secure authentication SSH method. To protect public and private key authentication keys, access to the files that contain the keys need to be restricted to the user who owns the keys.

Permissions on the directories or files that hold SSH keys must not allow write access to the UNIX group or other permission bits. For example, SSH does not work correctly if the permissions are 770, 775 or 777.

OpenSSH enables the StrictModes option by default. StrictModes disable the use of public and private key authentication if the required files are not properly protected to protect public key files when security is too relaxed.
Troubleshoot SSH
When you troubleshoot collective security problems where the controller cannot start or stop a member, or you cannot view or edit configuration files by using the Admin Center, if you disable StrictModes and the problem is solved, then the ownership, group, or world access to ssh directories or files that are related to public and private key authentication are incorrect. Correct the access and reenable StrictModes.


  1. Check the OpenSSH /etc/ssh/sshd_config daemon configuration file.

    The StrictModes option is enabled if it is set to yes, commented out, or not present. The StrictModes option might determine that security is too relaxed. As a result, the collective controller is unable to start a member because the SSH login to the server fails.

  2. For the user IDs that are associated with the controller and member servers, the user IDs must own and have the appropriate permissions for the following directories and files:
    Directory or file Permissions
    Home directory 700
    .ssh sub-directory under its home directory 700
    /.ssh/authorized_keys file 600
    /<server_config>/resources/security/ssh/ directory 700
    /<server_config>/resources/security/ssh/id_rsa file 600
    /<server_config>/resources/security/ssh/id_rsa.pub file 600, by default. You can change the permissions to 640 or 644 to make the public key readable.