The below post describes enabling the .ssh private key/public key process for the provided service IDs to avoid dependency on a password that may be forgotten, and also how to leverage the service IDs to address potential CA Directory data sync challenges that may occur when there are WAN network latency challenges between remote cluster nodes.
Background:
The CA/Broadcom/Symantec Identity Suite (IGA) solution provides for a software virtual appliance. This software appliance is available on Amazon AWS as a pre-built AMI image that allows for rapid deployment.
The software appliance is also offered as an OVA file for Vmware ESXi/Workstation deployment.
Challenge:
If the primary service ID is locked or password is allowed to expire, then the administrator will likely have only two (2) options:
1) Request assistance from the Vendor (for a supported process to reset the service ID – likely with a 2nd service ID “recoverip”)
2) Boot from an ISO image (if allowed) to mount the vApp as a data drive and update the primary service ID.
Proposal:
Add a standardized SSH RSA private/pubic key to the primary service ID, if it does not exist. If it exists, validate able to authentication and copy files between cluster nodes with the existing .SSH files. Rotate these files per internal security policies, e.g. 1/year.
The focus for this entry is on the CA ‘config’ and ‘ec2-user’ service IDs.
An enhancement request has been added, to have the ‘dsa’ userID added to the file’/etc/ssh/ssh_allowed_users’ to allow for the same .ssh RSA process to address challenges during deployments where the CA Directory Data DSA did not fully copy from one node to another node.

AWS vApp: ‘ec2-user’
The primary service ID for remote SSH access is ‘ec2-user’ for the Amazon AWS is already deployed with a .ssh RSA private/public key. This is a requirement for AWS deployments and has been enabled to use this process.

This feature allows for access to be via the private key from a remote SSH session using Putty/MobaXterm or similar tools. Another feature may be leveraged by updating the ‘ec2-user’ .ssh folder to allow for other nodes to be exposed with this service ID, to assist with the deployment of patch files.

As an example, enabling .ssh service between multiple cluster nodes will reduce scp process from remote workstations. Prior, if there were five (5) vApp nodes, to patch them would require uploading the patch direct to each of the five (5) nodes. With enabling .ssh service between all nodes for the ‘ec2-user’ service ID, we only need to upload patches to one (1) node, then use a scp process to push these patch file(s) from one node to another cluster node.
On-Prem vApp: ‘config’
We wish to emulate this process for on-prem vApp servers to reduce I/O for any files to be uploaded and/or shared.
This process has strong value when CA Directory *.db files are out-of-sync or during initial deployment, there may be network issues and/or WAN latency.
Below is an example to create and/or rotate the private/public SSH RSA files for the ‘config’ service ID.

Below is an example to push the newly created SSH RSA files to the remote host(s) of the vApp cluster. After this step, we can now use scp processes to assist with remediation efforts within scripts without a password stored as clear text.

Copy the RSA folder to your workstation, to add to your Putty/MobaXterm or similar SSH tool, to allow remote authentication using the public key.
If you have any issues, use the embedded verbose logging within the ssh client tool (-vv) to identify the root issue.
ssh -vv userid@remote_hostname
Example:
config@vapp0001 VAPP-14.1.0 (192.168.242.146):~ > eval `ssh-agent` && ssh-add Agent pid 5717 Enter passphrase for /home/config/.ssh/id_rsa: Identity added: /home/config/.ssh/id_rsa (/home/config/.ssh/id_rsa) config@vapp0001 VAPP-14.1.0 (192.168.242.146):~ > config@vapp0001 VAPP-14.1.0 (192.168.242.146):~ > ssh -vv config@192.168.242.128 OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug2: ssh_connect: needpriv 0 debug1: Connecting to 192.168.242.128 [192.168.242.128] port 22. debug1: Connection established. debug1: identity file /home/config/.ssh/identity type -1 debug1: identity file /home/config/.ssh/identity-cert type -1 debug2: key_type_from_name: unknown key type '-----BEGIN' debug2: key_type_from_name: unknown key type 'Proc-Type:' debug2: key_type_from_name: unknown key type 'DEK-Info:' debug2: key_type_from_name: unknown key type '-----END' debug1: identity file /home/config/.ssh/id_rsa type 1 debug1: identity file /home/config/.ssh/id_rsa-cert type -1 debug1: identity file /home/config/.ssh/id_dsa type -1 debug1: identity file /home/config/.ssh/id_dsa-cert type -1 debug1: identity file /home/config/.ssh/id_ecdsa type -1 debug1: identity file /home/config/.ssh/id_ecdsa-cert type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3 debug1: match: OpenSSH_5.3 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.3 debug2: fd 3 setting O_NONBLOCK debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-dss-cert-v00@openssh.com,ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se debug2: kex_parse_kexinit: hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96 debug2: kex_parse_kexinit: hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96 debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se debug2: kex_parse_kexinit: hmac-sha1,hmac-sha2-256,hmac-sha2-512 debug2: kex_parse_kexinit: hmac-sha1,hmac-sha2-256,hmac-sha2-512 debug2: kex_parse_kexinit: none debug2: kex_parse_kexinit: none debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_setup: found hmac-sha1 debug1: kex: server->client aes128-ctr hmac-sha1 none debug2: mac_setup: found hmac-sha1 debug1: kex: client->server aes128-ctr hmac-sha1 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<2048<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug2: dh_gen_key: priv key bits set: 141/320 debug2: bits set: 1027/2048 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Host '192.168.242.128' is known and matches the RSA host key. debug1: Found key in /home/config/.ssh/known_hosts:2 debug2: bits set: 991/2048 debug1: ssh_rsa_verify: signature correct debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug2: key: /home/config/.ssh/id_rsa (0x5648110d2a00) debug2: key: /home/config/.ssh/identity ((nil)) debug2: key: /home/config/.ssh/id_dsa ((nil)) debug2: key: /home/config/.ssh/id_ecdsa ((nil)) debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password debug1: Next authentication method: gssapi-keyex debug1: No valid Key exchange context debug2: we did not send a packet, disable method debug1: Next authentication method: gssapi-with-mic debug1: Unspecified GSS failure. Minor code may provide more information Improper format of Kerberos configuration file debug1: Unspecified GSS failure. Minor code may provide more information Improper format of Kerberos configuration file debug2: we did not send a packet, disable method debug1: Next authentication method: publickey debug1: Offering public key: /home/config/.ssh/id_rsa debug2: we sent a publickey packet, wait for reply debug1: Server accepts key: pkalg ssh-rsa blen 533 debug2: input_userauth_pk_ok: SHA1 fp 39:06:95:0d:13:4b:9a:29:0b:28:b6:bd:3d:b0:03:e8:3c:ad:50:6f debug1: Authentication succeeded (publickey). debug1: channel 0: new [client-session] debug2: channel 0: send open debug1: Requesting no-more-sessions@openssh.com debug1: Entering interactive session. debug2: callback start debug2: client_session2_setup: id 0 debug2: channel 0: request pty-req confirm 1 debug1: Sending environment. debug1: Sending env LANG = en_US.UTF-8 debug2: channel 0: request env confirm 0 debug2: channel 0: request shell confirm 1 debug2: fd 3 setting TCP_NODELAY debug2: callback done debug2: channel 0: open confirm rwindow 0 rmax 32768 debug2: channel_input_status_confirm: type 99 id 0 debug2: PTY allocation request accepted on channel 0 debug2: channel 0: rcvd adjust 2097152 debug2: channel_input_status_confirm: type 99 id 0 debug2: shell request accepted on channel 0 Last login: Thu Apr 30 20:21:48 2020 from 192.168.242.146 CA Identity Suite Virtual Appliance version 14.3.0 - SANDBOX mode FIPS enabled: true Server IP addresses: 192.168.242.128 Enabled services: Identity Portal 192.168.242.128 [OK] WildFly (Portal) is running (pid 10570), port 8081 [OK] Identity Portal Admin UI is available [OK] Identity Portal User Console is available [OK] Java heap size used by Identity Portal: 810MB/1512MB (53%) Oracle Database Express 11g 192.168.242.128 [OK] Oracle Express Edition started Identity Governance 192.168.242.128 [OK] WildFly (IG) is running (pid 8050), port 8082 [OK] IG is running [OK] Java heap size used by Identity Governance: 807MB/1512MB (53%) Identity Manager 192.168.242.128 [OK] WildFly (IDM) is running (pid 5550), port 8080 [OK] IDM environment is started [OK] idm-userstore-router-caim-srv-01 started [OK] Java heap size used by Identity Manager: 1649MB/4096MB (40%) Provisioning Server 192.168.242.128 [OK] im_ps is running [OK] co file usage: 1MB/250MB (0%) [OK] inc file usage: 1MB/250MB (0%) [OK] main file usage: 9MB/250MB (3%) [OK] notify file usage: 1MB/250MB (0%) [OK] All DSAs are started Connector Server 192.168.242.128 [OK] jcs is running User Store 192.168.242.128 [OK] STATS: number of objects in cache: 5 [OK] file usage: 1MB/200MB (0%) [OK] UserStore_userstore-01 started Central Log Server 192.168.242.128 [OK] rsyslogd (pid 1670) is running... === LAST UPDATED: Fri May 1 12:15:05 CDT 2020 ==== *** [WARN] Volume / has 13% Free space (6.2G out of 47G) config@cluster01 VAPP-14.3.0 (192.168.242.128):~ >
A view into rotating the SSH RSA keys for the CONFIG UserID
# CONFIG - On local vApp host ls -lart .ssh [view any prior files] echo y | ssh-keygen -b 4096 -N Password01 -C $USER -f $HOME/.ssh/id_rsa IP=192.168.242.135;ssh-keyscan -p 22 $IP >> .ssh/known_hosts IP=192.168.242.136;ssh-keyscan -p 22 $IP >> .ssh/known_hosts IP=192.168.242.137;ssh-keyscan -p 22 $IP >> .ssh/known_hosts cp -r -p .ssh/id_rsa.pub .ssh/authorized_keys rm -rf /tmp/*.$USER.ssh-keys.tar tar -cvf /tmp/`/bin/date -u +%s`.$USER.ssh-keys.tar .ssh ls -lart /tmp/*.$USER.ssh-keys.tar eval `ssh-agent` && ssh-add [Enter Password for SSH RSA Private Key] IP=192.168.242.136;scp `ls /tmp/*.$USER.ssh-keys.tar` config@$IP: IP=192.168.242.137;scp `ls /tmp/*.$USER.ssh-keys.tar` config@$IP: USER=config;ssh -tt $USER@192.168.242.136 "tar -xvf *.$USER.ssh-keys.tar" USER=config;ssh -tt $USER@192.168.242.137 "tar -xvf *.$USER.ssh-keys.tar" IP=192.168.242.136;ssh $IP `/bin/date -u +%s` IP=192.168.242.137;ssh $IP `/bin/date -u +%s` IP=192.168.242.136;ssh -vv $IP [Use -vv to troubleshoot ssh process] IP=192.168.242.137;ssh -vv $IP [Use -vv to troubleshoot ssh process]