WebSphere Application Server & Liberty

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 wsadmin script for WebSphere Application Server or server script for WebSphere Liberty.

For this example, we'll be executing the subsequent commands from a terminal with oc command in the PATH. The first step in setting up secure access is to generate a new SSH key for WebSphere Automation using the ssh-keygen command.
[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:
SHA256:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX root@XXXXX.ibm.com
The key's randomart image is:
+---[RSA 3072]----+
| =&=+|
| .+ ==|
| ...=*|
| ...*+=|
| S . .*o=+|
| . .=o+o=|
| .o.B+|
| +.=|
| E@|
+----[SHA256]-----+


The next step is to copy the public key to each server using the ssh-copy-id command.
[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
[USER@HOSTNAME ~]$


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
secret/wsa-ansible created


Finally, configure WebSphere Automation with a list of known hosts and their public keys that WebSphere Automation will trust. Use the ssh-keyscan 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
configmap/wsa-ansible-known-hosts created


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
pod/wsa-runbook-manager-5b7594744c-hp67q
[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
INFO: starting
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.
#websphere#automation#WSA#WebSphereAutomation​​​