Configure the satellite remote execution to use SSH key other than foreman-proxy SSH key
Environment
- Red Hat Satellite 6
Issue
- After creating a separate user for remote execution , the foreman-proxy's SSH key is still used for remote execution.
Resolution
-
Setup Remote Execution using non-root user on RHEL systems connected to Red Hat Satellite 6.
-
Create an SSH key pair and choose the desired location for it, or using an existing one:
# ssh-keygen -
Run the following command on both satellite and the capsules to set the directory where SSH keys are stored and the private SSH key name :
#### For Red Hat Satellite\Capsule 6.11 or below: # satellite-installer --foreman-proxy-plugin-remote-execution-ssh-ssh-identity-dir [Directory where SSH keys are stored] \ --foreman-proxy-plugin-remote-execution-ssh-ssh-identity-file [Private SSH key filename] #### For Red Hat Satellite\Capsule 6.12 and later: # satellite-installer --foreman-proxy-plugin-remote-execution-script-ssh-identity-dir [Directory where SSH keys are stored] \ --foreman-proxy-plugin-remote-execution-script-ssh-identity-file [Private SSH key filename]Note: Use only the filename for argument
foreman-proxy-plugin-remote-execution-(script/ssh)-ssh-identity-file, i.e.--foreman-proxy-plugin-remote-execution-(script/ssh)-ssh-identity-file id_rsa -
Ensure that the foreman-proxy user can access and read the new SSH keypair without any issues.
# su - foreman-proxy -s /bin/bash -c "ls -l /PATH/TO/NEW/SSH/KEYPAIR/DIRECTORY/" # curl -vvv https://<satellite or capsule fqdn>:9090/ssh/pubkey-
If either or both of the command returns Access Denied or Permission Denied, then set appropriate permission or ACL for the directory where SSH keys are stored.
-
The easiest way to do that would be setting an ACL for the foreman-proxy user as displayed below.
# setfacl -R -m u:foreman-proxy:rwx /PATH/TO/NEW/SSH/KEYPAIR/DIRECTORY/
-
For more KB articles/solutions related to Red Hat Satellite 6.x Remote Execution Issues, please refer to the Red Hat Satellite Consolidated Troubleshooting Article for Red Hat Satellite 6.x Remote Execution Issues
Root Cause
- The satellite is configured by default to use the foreman-proxy SSH key to run the remote execution.
This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.
9 Comments
In RH Satellite/Capsule 6.12 version below parameters are not available, how this works in 6.12 version ? could you please provide solution for this --foreman-proxy-plugin-remote-execution-ssh-ssh-identity-dir --foreman-proxy-plugin-remote-execution-ssh-ssh-identity-file
You can use
--foreman-proxy-plugin-remote-execution-script-ssh-identity-dirand--foreman-proxy-plugin-remote-execution-script-ssh-identity-filestarting from Satellite 6.12thanks Sayan
Hi Sayan, we are using non-root user as "rexuser" on capsule server and client host. 1. generated ssh key for rexuser on capsule and copied ssh key to client host using ssh-copy-id 2. Executed below command on external capsule. satellite-installer --scenario capsule --foreman-proxy-plugin-remote-execution-script-ssh-identity-dir [Directory where SSH keys are cution-script-ssh-identity-file [Private SSH key filename]. after above command permission of /home/rexuser/.ssh is changed to foreman-proxy
Are the above steps correct?. or Should we use foreman-proxy account to create the ssh key & copy to the client using rexuser.
First you have to understand is that, Whether it's satellite or capsule, No matter which SSH key you use for which user, foreman-proxy user is the initiator for any remote execution job.
i.e. for your case, foreman-proxy user of capsule, would make use of the ssh keys stored inside /home/rexuser/.ssh to initiate the SSH connectivity to the target client systems. And to do so, The foreman-proxy user needs to have the access to those keys .
So it's not
Capsule's rexuser to -> Client's rexuser
It's
Capsules's foreman-proxy user using ssh keys of rexuser -> Client's rexuser
I hope that explains the behavior you are observing.
thanks for the response Sayan, now ssh key permission of the user "rexuser" has been changed to foreman-proxy(rwx) which means foreman-proxy is having full access to rexuser ssh key folder and "rexuser" is not having access to its own ssh key folder/directory in this case which user we have to mention in Satellite UI under Administer-->>settings-->>Remote Execution-->> SSH User and Effective user
Well, You can manually change the permissions if you want. i.e. use chown to change the User-level ownership of that .ssh directory recursively to rexuser and repeate the same for group ownership for foreman-proxy on the same dir recursively.
But it should not matter as the rexuser of the capsule itself would not be used for anything , unless you have to use it for something. It's foreman-proxy user only that will initiate the remote execution to rexuser@client-host
And about the Administer-->>settings-->>Remote Execution page, I recommend setting
SSH User: rexuser
Effective user : root
The idea is, foreman-proxy of capsule will SSH to target system as rexuser, use sudo to become root and then run the job as root user.
In that way, both normal and ansible based job executions will work.
thanks Sayan, when i invoke remote execution job for content host i am getting below error error while initializing command RuntimeError Failed to establish connection to remote host, exit code: 255:"
followed this link https://access.redhat.com/solutions/7004687 but solution is in progress
Hello Sachin,
I will recommend you open a support case with Red Hat and have the issue properly investigated as per your environment.
-- Sayan