Bug 2160902

We would have to do this for all capsules as well, not only for satellite. The downside is that if we did this and someone renamed their capsule, then they would lose access to any host that was being managed through it. In general this feels like it has a great footgun potential, but I'll leave that to other to decide.

If we decide to do this, this will be an easy fix.

We'd very much like to see this RFE enacted as soon as possible, please.

I don't see a real problem with this for the (relative infrequent) case of someone renaming their capsules. 

There is already a procedure you have to go through, (see e.g.  
https://access.redhat.com/documentation/en-us/red_hat_satellite/6.9/html/administering_red_hat_satellite/sect-red_hat_satellite-administering_red_hat_satellite-renaming_a_server), so it is just a step has to be added to that.

I would like to see this implemented soon, please.

I think this is a great idea. There are couples of things to be considered. As Adam mentioned, all Capsules with REX feature would have to be listed. Another thing is, DNS is not always configured correctly and Satellite may not even know, what the record resolves to on managed hosts. Due to this, the functionality should be opt-in. Due to the DNS aspect, I'd suggest we introduce a Parameter "remote_execution_ssh_keys_accepted_from" which users would fill in (either globally, per host group etc). If some value is specified in there, it would be used in the configuring template.

Two other things to mention. To increase the security, the private keys that Satellite use can also be protected with the passphrase. Such passphrase then needs to be used every time the REX job is triggered.

Second - the requested functionality can already be implemented today. User can unlock and edit the default "remote_execution_ssh_keys" provisioning template snippet. This snippet is used both from provisioning templates and during the registration process. The lines that needs to be adjusted is 

  cat << EOF >> <%= ssh_path %>/authorized_keys
<%= host_param('remote_execution_ssh_keys').is_a?(String) ? host_param('remote_execution_ssh_keys') : host_param('remote_execution_ssh_keys').join("\n") %>
EOF

it would be slightly more complicated, but the following should do the trick

  cat << EOF >> <%= ssh_path %>/authorized_keys
<% if host_param('remote_execution_ssh_keys').is_a?(String) -%>
from=satellite.example.com <%= host_param('remote_execution_ssh_keys') -%>
<% else -%>
<%=  host_param('remote_execution_ssh_keys').map { |key| "from=satellite.example.com #{key}"}.join("\n") %>
<% end -%>
EOF

the satellite.example.com can be easily replaced with the parameter I mentioned above. Just keep in mind that with every update, the snippet will get restored. If you'd like to keep it persistent, you'd have to clone it and update your kickstart templates to use this new clone.

Upon review of our valid but aging backlog the Satellite Team has concluded that this Bugzilla does not meet the criteria for a resolution in the near term, and are planning to close in a month. This message may be a repeat of a previous update and the bug is again being considered to be closed. If you have any concerns about this, please contact your Red Hat Account team.  Thank you.

Based upon feedback during auto-closure, leaving this bugzilla open a while longer for additional discussion; however, it may be closed in a future iteration.

This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there.

Due to differences in account names between systems, some fields were not replicated.  Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information.

To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "SAT-" followed by an integer.  You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like:

"Bugzilla Bug" = 1234567

In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. You can also visit https://access.redhat.com/articles/7032570 for general account information.