Understand the default impersonation is using SSH.
1) Can we reconfigure agent to use system SSH instead of RA SSH?
2) How's the mechanism work? Does it SSH to localhost or IP or other mechanism?
3) Since it's using SSH, is it possible to configure key exchange to impersonated ID? The objective is to have passwordless usage. (SUDO impersonation is a no go at client side).
I have recently come across an issue where the notion of using SSH keys was desired. While researching the issue I came across this community post that was unanswered. Further research confirmed answers to your questions:
2. The mechanism uses 127.0.0.1
3. I have confirmed that this is not possible in the current implementation of SSH connections. Please submit an "IDEA" for this feature.
I have found a workaround to the problem.
Using the same sudo impersonation configuration, I scripted the customActionRunner.sh to execute ssh instead of sudo. With that, the key exchange will work, so password no longer needed in "Set Credentials" field.
But it's a dirty hack. Will request as formal feature.
Thanks for the update! Please mark this thread as Answered if the information provided is sufficient, and definitely create an Idea here int he Communities so the request will be official and can be voted up by other customers.
Hi, I need further information about how SSH works on this, our security group needs it to authorize it use. Is there any documentation about it? What agent files are used? What about certificate authorization?
You might want to start a separate thread if you think you need information not covered by the questions/answers given here. But I will try and answer one of your questions:
What agent files are used?
[answer] First, we need to be mindful that the topic here is impersonation. And impersonation has two options (ssh is the default, and sudo). Within that context, I *believe* it does not use any agent files, like it does when it impersonates using sudo, because the agent isn't actually creating a sub/separate NolioAgent process (which initiates and runs in a similar context in terms of loading with jars, updating logs, files, etc..). In the default ssh mode it connects to the local machine using 127.0.0.1 and does what it needs to do in the shell environment provided by that users connection.
As for certificate authorization, I'm unclear on what is being asked.
I was curious, are you referring to public key authentication via ssh to avoid using a password as you mentioned?
Yes Jeremy, our security group doesn't approve to have both public and private key on the same server.