Bug 2160902

Summary: [RFE] Securing remote execution ssh key for provisioned hosts with 'from=Satellite.example.com' prefix
Product: Red Hat Satellite Reporter: Krutika Kinge <kkinge>
Component: Remote ExecutionAssignee: satellite6-bugs <satellite6-bugs>
Status: NEW --- QA Contact: Satellite QE Team <sat-qe-bz-list>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 6.12.0CC: aruzicka, ben.argyle, cylopez, dsinglet, emil.sylvio.golinelli, jesper.schmidt, terje.trane
Target Milestone: UnspecifiedKeywords: EasyFix, FutureFeature, Triaged
Target Release: Unused   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Krutika Kinge 2023-01-14 09:27:30 UTC
1. Proposed title of this feature request
Securing remote execution ssh key for provisioned hosts with 'from=<Satellite.example.com>' prefix

2. What is the nature and description of the request?
When a host is provisioned from a Satellite server. the Satellite server's public ssh key is added to the root's autherized_keys file.

The entry added to authorized keys does not limit from where the key is valid, if the private key gets copied it can be used to take root access of the server from any other host.

The entry in authorized_keys should use a from=”satellite.example.com” prefix to limit the key to only be valid from the satellite.


3. Why does the customer need this
its a major security concern for using remote execution at the moment

4. How would the customer like to achieve this?
 a prefix in autherized_keys file with satellite hostname: from=”satellite.example.com”

5. Is there already an existing RFE upstream or in Red Hat Bugzilla?
   No

6. Does the customer have any specific timeline dependencies and which release would they like to target (i.e. RHEL5, RHEL6)?
No

7.  Is the sales team involved in this request and do they have any additional input?
No

8. 10. List any affected packages or components.
Remote execution, provisioning

9. Would the customer be able to assist in testing this functionality if implemented?
yes

Comment 1 Adam Ruzicka 2023-01-16 09:23:43 UTC
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.

Comment 2 Ben 2023-01-16 10:35:10 UTC
We'd very much like to see this RFE enacted as soon as possible, please.

Comment 3 terje.trane 2023-01-16 12:10:27 UTC
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.

Comment 4 Emil 2023-01-16 12:31:04 UTC
I would like to see this implemented soon, please.

Comment 5 Marek Hulan 2023-01-20 13:59:13 UTC
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.