Symantec Identity Manager - How to use ssh key enabled authentication with CA Identity Manager (IM)?
Article ID: 196345
Updated On:
Products
Issue/Introduction
How to use ssh key enabled authentication with CA Identity Manager (IM)?
When using ssh (secure shell) errors are returned:
Warning: Identity file /opt/CA/VirtualAppliance/conf/wildfly-ssh-keys/imadmin_key not accessible: Permission denied.
spawn ssh -oStrictHostKeyChecking=no -oCheckHostIP=no localhost
imadmin@localhost's password:
Permission denied, please try again.
imadmin@localhost's password:
Permission denied, please try again.
Environment
Release : 14.x
Component : CA IDENTITY SUITE (VIRTUAL APPLIANCE)
Resolution
How to use Key-based Authentication
The CA Identity Manager (IM) offers some details on how to "Enable Key-Based Authentication to a Remote SSH Server", but the documentation lacks context.
In the context of CA Identity Manager "Key-based authentication" is designed to work through Policy Xpress gaining access via the wildfly user. If you try to execute the commands directly at the OS Level, you will receive a "permission denied" error.
To use "Key-Based Authentication to a Remote SSH Server", a key pair needs to be created and exported to the remote machine.
To generate a public key follow the steps below :
1. wildfly-ssh-keymgr --generate config_key
2. wildfly-ssh-keymgr --list
3. wildfly-ssh-keymgr --export config_key
Note that config_key can be any name you want and is just an example as you can create multiple keys with unique names. Also note that the generated keys are not replicated across different nodes and each vApp node would need to have the generate key run to generate the key and then the export command run in order to get the public to that is to be copied out to the remote machine. There is also a remove command that can be used to removed keys no longer needed too.
For Linux (Confirmed):
Copy the public key (config_key.pub) to the remote Linux machine and add the public key to the root/.ssh/authorized_keys directory.
For Windows (Unconfirmed):
Copy the public key (config_key.pub) to the remote Windows machine and add the public key to the C:/Users/YourUserName/.ssh/ directory.
Note that if the exported public keys from multiple vApp nodes need to be copied to a remote machine you may need to concatenate the contents of all the public keys into a single file to be used on that remote machine since each vApp node will have a unique private key generated and a unique public key exported for it.
Although the commands need to be instigated from Policy Express (PX), they must be run from a ssh script.
For example, create a new file (test_ssh), with the following code syntax:
ssh -o StrictHostKeyChecking=no -i /opt/CA/VirtualAppliance/conf/wildfly-ssh-keys/<key name> user@<host> "<command>"
i.e.:
ssh -o StrictHostKeyChecking=no -i /opt/CA/VirtualAppliance/conf/wildfly-ssh-keys/imadmin_key [email protected] "mkdir /root/NewFolder"
Create a Px Policy in CA Identity Manager (IM) with the following action rules:
Category = External Code
Type = Execute Command Line
Function = Execute Command Line
Command: /home/config/test_ssh
Outcomes:
When executed this triggers the PxPolicy which then creates the "newFolder" on my remote machine.
Additional Information
If you are getting an error such as the following in the Windows Event Viewer under the OpenSSH Operational log:
sshd: Failed password for ssh_user from ###.###.#.### port 34976 ssh2
Then it can be helpful to enable DEBUG level logging for sshd but since we do not have permissions to edit the /etc/ssh/sshd_config file on the vApp node to set DEBUG logging you can instead set up the logging on the Windows side by editing the C:\ProgramData\ssh\sshd_config file where you would need to set the following two properties and then restart the "OpenSSH SSH Server" service:
SyslogFacility LOCAL0
LogLevel Debug3
You can then repeat another test case and can check the C:\ProgramData\ssh\logs\sshd.log for errors perhaps such as the following error:
8152 2024-11-20 02:56:04.789 debug1: trying public key file C:\\Windows\\.ssh/authorized_keys
8152 2024-11-20 02:56:04.790 debug3: Failed to open file:C:/Windows/.ssh/authorized_keys error:2
8152 2024-11-20 02:56:04.790 debug1: Could not open authorized keys 'C:\\Windows\\.ssh/authorized_keys': No such file or directory
At this point you could move the .ssh\authorized_keys from the C:\Users\ssh_user location to the C:\Windows location since for whatever reason that is where the Windows machine is looking for it. Restart the "OpenSSH SSH Server" service again and retest again and see if it works or if there is additional errors related to permission such as:
7760 2024-11-20 02:58:31.303 debug1: trying public key file C:\\Windows\\.ssh/authorized_keys
7760 2024-11-20 02:58:31.304 debug3: Bad permissions. Try removing permissions for user: ##### on file C:/Windows/.ssh/authorized_keys.
7760 2024-11-20 02:58:31.305 Authentication refused.
8580 2024-11-20 03:06:23.116 debug1: trying public key file C:\\Windows\\.ssh/authorized_keys
8580 2024-11-20 03:06:23.118 debug3: Bad permissions. Try removing permissions for user: ##### on file C:/Windows/.ssh/authorized_keys.
8580 2024-11-20 03:06:23.118 Authentication refused.
If so then check the security properties of the C:\\Windows\\.ssh\authorized_keys file. It could be that it has additional non-Full Control settings in which case try to modify the security on the file to remove everything except for SYSTEM and Administrators which both should have Full Control of the file. Restart the "OpenSSH SSH Server" service again and retest again and see if it now works.
Feedback
