WebSphere Automation "How To" Series #8 : How to setup secure access to Linux or UNIX servers
Previous blogs in this WebSphere Automation "How To" series :WebSphere Automation "How To" Series #1 : How to get WebSphere Automation UI WebSphere Automation "How To" Series #2 : How to specify user roles and permissions WebSphere Automation "How To" Series #3 : How to configure WebSphere Automation with an Enterprise LDAP WebSphere Automation "How To" Series #4 : How to register WebSphere Application Server traditional servers using configuretWasUsageMetering.py script WebSphere Automation "How To" Series #5 : How to register WebSphere Liberty servers WebSphere Automation "How To" Series #6 : How to configure email server and email addresses for notifications WebSphere Automation "How To" Series #7 : How to setup Instana to send alerts to WebSphere Automation
This post will focus on how to setup secure access to Linux or UNIX servers.
Before performing health monitoring for your registered servers, both WebSphere Automation and the registered servers must be configured to communicate using SSH. Each host with a server to be managed by WebSphere Automation must have SSH enabled and running. To generate a heap dump as a part of memory leak analysis, the user must have permission to invoke the
script for WebSphere Application Server or
script for WebSphere Liberty.
For this example, we'll be executing the subsequent commands from a terminal with
command in the PATH. The first step in setting up secure access is to generate a new SSH key for WebSphere Automation using the
[root@XXXXX.ibm.com wsa-install]# ssh-keygen -f ~/.ssh/wsa
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/wsa.
Your public key has been saved in /root/.ssh/wsa.pub.
The key fingerprint is:
The key's randomart image is:
| .+ ==|
| S . .*o=+|
| . .=o+o=|
The next step is to copy the public key to each server using the
[root@XXXXX.ibm.com wsa-install]# ssh-copy-id -i ~/.ssh/wsa USER@HOSTNAME
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/root/.ssh/wsa.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
Number of key(s) added: 1
Now try logging into the machine, with: "ssh 'USER@HOSTNAME'"
and check to make sure that only the key(s) you wanted were added.
Validate that you can use SSH to communicate with the server.
[root@XXXXX.ibm.com wsa-install]# ssh -i ~/.ssh/wsa USER@HOSTNAME
Last login: Mon Apr 25 09:49:20 2022 from xx.xx.xx.xx
The next step is to create the wsa-ansible secret in the WebSphere Automation namespace with your SSH connection parameters.
[root@XXXXX.ibm.com wsa-install]# oc create secret generic wsa-ansible --from-literal=ansible_user=USER --from-literal=ansible_port=22 --from-file=ssh_private_key_file=/root/.ssh/wsa --from-literal=ssh_private_key_password=PASSWORD
Finally, configure WebSphere Automation with a list of known hosts and their public keys that WebSphere Automation will trust. Use the
command to create a known_hosts file fore each server registered with WebSphere Automation.
ssh-keyscan HOSTNAME >> ~/.ssh/wsa_known_hosts
Create the wsa-ansible-known-hosts configmap resource with the known hosts file in the WebSphere Automation namespace.
[root@XXXXX.ibm.com wsa-install]# oc create configmap wsa-ansible-known-hosts --from-file=known_hosts=/root/.ssh/wsa_known_hosts
This configmap 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 updated SSH keys.
Now that we've setup secure access to our servers, we can validate remote access between WebSphere Automation and the registered servers by running the 'runcli testConnection' command. The 'runcli testConnection' command can be run from a console of the runbook-manager pod.
[root@XXXXX.ibm.com wsa-install]# MANAGER_POD=$(oc get pod -l app.kubernetes.io/component=runbook-manager -o name | head -n 1)
[root@XXXXX.ibm.com wsa-install]# echo $MANAGER_POD
[root@XXXXX.ibm.com wsa-install]# oc rsh $MANAGER_POD runcli testConnection HOSTNAME linux
Apr 25, 2022 5:16:08 PM com.ibm.ws.automation.core.runbook.manager.RunbookManagerCLI clientMode
Created job: test-connection-1650906970011
To see the job logs run: oc logs --tail=100 -l job-name=test-connection-1650906970011
You can view the logs with the reported command and look for a return code of 0 to confirm that the testConnection was successful.
[root@XXXXX.ibm.com wsa-install]# oc logs --tail=100 -l job-name=test-connection-1650906970011 | grep return\ code
[04/25/22 17:16:53:675 UTC] 1 com.ibm.ws.automation.core.runbook.runner.RunbookRunnerCLI INFO start Ansible return code=0
You can find more IBM Docs related to WebSphere Automation at https://www.ibm.com/docs/en/ws-automation
and more specific information on setting up secure remote access at https://www.ibm.com/docs/en/ws-automation?topic=monitoring-setting-up-secure-remote-access