SSH script automation provider

Edit online

Use a script automation provider to connect to your back-end system (targets). The SSH Provider is agentless and connects directly to the target machine. It authenticates by using public key-based authentication in SSH.

The script automation provider works for back-end systems (targets) running UNIX or Windows. For UNIX, the user running the automation must have sufficient rights to run these features.
  • bash – a shell that is used to wrap and run the specified commands or script.
  • mktemp – A utility that is used to create a temporary file, which is required for the script execution with this automation provider to work.
  • openssl – A utility that is used on the target system to decrypt the transferred commands or script.

Defining which RBA user is allowed to run an automation

The current public key must be added to all target machines that you plan to run scripts on via the SSH Provider. Make sure that you add the public key in the correct repository so that the script can be ran:
  • By the root user.
  • By specific users on this target. For example, by putting the key in the authorized_keys file of home directory of these specific users.

Depending on the public key used, any RBA user or only members of specific RBA groups are able to access the target system. See step 5 in the following procedure for more information about creating public keys for specific groups.

Defining which UNIX or Windows user is used to run an automation

By default, scripts are run on the target machine by using the root username. It is possible to run the script with a different UNIX or Windows user. The username can either be fixed or depend on the RBA user that is logged in. For more information, see Creating Script automations.

Defining an SSH jump server

An optional SSH jump server can be specified. If chosen, any connections to target systems are routed through this jump server. See step 3 for more information about using a jump server.
Note: The jump server must be a UNIX system (including Linux and AIX®). The jump server cannot be a Windows system.

Configuring an SSH script automation provider

Edit online

About this task

You can configure a connection on the Connections page. Click Configure on the Script tile to open the configuration window and follow the on-screen instructions.

Procedure

  1. In the Navigation icon main navigation menu, select Adjust settings icon Administration and click Integration with other systems.
  2. Click Automation type.
  3. Click Configure on the Script tile.
  4. If you are using a jump server you must configure it.

    Depending on your environment, you might require a jump server to access your target endpoints. A jump server is an SSH endpoint that is used to connect to the nested SSH endpoints. This is a common approach that is used to communicate between different network zones. To use a jump server with RBA it must have an SSH server running and the nc command must be available. This is used to connect to nested SSH target endpoints.

    Click Use a jump server and specify the following jump server credentials:
    Jump server address
    The hostname or IP address of the jump server.
    Jump server port
    The SSH port of the jump server.
    Jump server username
    The username for authentication on the jump server.
    Jump server password
    The password for authentication on the jump server.
    Any connections to SSH target endpoints use the specified jump server.

    If you are using the secure gateway client when a jump server is specified, the connection between the secure gateway client and the target endpoint will use the jump server.

  5. On your target machine, register the default public key to enable access to the target endpoints via SSH for all users.
    Configuring SSH public key authentication for the UNIX root user
    The displayed public key must be added to all target machines that you plan to run scripts on via the SSH Provider. This key enables any RBA user to run script automations on the given target endpoint. The key must be added to the authorized_keys file that is usually found in the /root/.ssh/authorized_keys folder.
    Configuring SSH public key authentication for a specific UNIX user
    If you want to enforce that only a specific UNIX user can run the script on this target endpoint you should copy the key to the authorized_keys file in the home directory of the specific user, for example /home/john/.ssh/authorized_keys.
    You can regenerate the public key by clicking the refresh button of the public key.
    Note: Regenerating the public key deletes the old key pair. If you choose to regenerate the key pair you must exchange the public key in each target machine that you plan to access via the SSH Provider.

    For more information about how to configure which UNIX user is used to run the script, see Creating Script automations.

  6. Optionally, you can generate group-specific keys. Use these if you only want users from a specific group to have access to a machine.

    In this scenario, the default public key can act as a fallback if none of the other keys work.

    1. Click New public key for groups.
    2. Select a group, then use the refresh button to create a public key for the selected group.
    3. The table lists all existing group-specific keys. Use the action buttons to change, delete, or copy the public keys.
    Note: Runbook Automation tries every eligible public key for an RBA user to access a target endpoint until it finds an authorized public key. Some target endpoints might have security policies in place that ban further connection after a certain number of unauthorized connections. Therefore, it is good practice to either avoid having too many group-specific public keys or avoid having RBA users in too many different groups.