Setting up WebSphere Automation for SSH to Linux or UNIX servers

To apply security fixes or to collect the heap dump information from managed servers, both WebSphere Automation and the servers must be properly configured to communicate with SSH. Configure WebSphere Automation to use SSH with your Linux® or UNIX servers.

Before you begin

Make sure that servers to be managed meet the prerequisites in Managed server requirements.

Procedure

Create the wsa-ansible secret in the WebSphere Automation namespace with your SSH connection parameters:
```
oc create secret generic wsa-ansible \
   --from-literal=ansible_user=<ssh_username> \
   --from-literal=ansible_port=<ssh_port> \
   --from-file=ssh_private_key_file=<ssh_private_key_file> \
   --from-literal=ssh_private_key_password=<ssh_private_key_passphrase> \
   --from-literal=ansible_python_interpreter=<path_to_python>
```
Due to Ansible requiring the encoding to be set to UTF-8, if you are unable to manually configure your locale, you can configure a temporary locale and encoding to be used during the execution of the playbooks.
To do this, during secret creation, you can configure the locale by adding the following:
```
--from-literal=ansible_wsa_locale=en_US.UTF-8
```
You must ensure that the locale and encoding exist on your machine.
Refer to the following example.
```
oc create secret generic wsa-ansible \
   --from-literal=ansible_user=wsadmin \
   --from-literal=ansible_port=22 \
   --from-file=ssh_private_key_file=/home/admin/.ssh/wsa \
   --from-literal=ssh_private_key_password=changeme \
   --from-literal=ansible_python_interpreter=/usr/local/bin/python3.9 \
   --from-literal=ansible_wsa_locale=en_US.UTF-8
```
If your SSH private key is not encrypted, the ssh_private_key_password parameter is not needed. Other connection parameters can also be passed in the same way. See the Ansible documentation for full parameters list.

If the Python executable on the target machine is not in the system path, or is not named python or python3, the ansible_python_interpreter parameter must added during the secret creation.

If you have a target server with an AIX operating system, and if both the connection user and the become_user are unprivileged, you might encounter a runtime error that can be prevented during secret creation. For more information, see iFix installation on a target server with an AIX operating system fails with error chmod: A flag or octal number is not correct.
Configure WebSphere Automation with a list known hosts and their public keys that WebSphere Automation can trust.
Even though WebSphere Automation connects only to hosts that are registered with WebSphere Automation, this step prevents impersonation or man-in-the-middle attacks.
1. Use the ssh-keyscan command to create a known_hosts file for each server registered with WebSphere Automation:
```
ssh-keyscan <host> >> <known_hosts_file>
```
  Refer to the following example.
```
ssh-keyscan myvm1 >> ./wsa_known_hosts
ssh-keyscan myvm2 >> ./wsa_known_hosts
```
2. Create the wsa-ansible-known-hosts configmap resource with the known hosts file:
```
oc create configmap wsa-ansible-known-hosts --from-file=known_hosts=<your known_hosts file>
```
  Refer to the following example.
```
oc create configmap wsa-ansible-known-hosts --from-file=known_hosts=./wsa_known_hosts
```
Important: This configmap with known hosts must be kept up to date with the registered servers and their public SSH keys. WebSphere Automation cannot connect to servers that are not in the list or which have SSH keys that are updated.