Description of problem: Currently, spacewalk-splice-tool logs in as a user on the spacewalk machine via an ssh key, and runs three "spacewalk-report" commands. However, a root user on the SAM host can use the ssh key to obtain a shell on the spacewalk machine, even though the script does not need a full shell. Instead, the remote login should be constrained, possibly by setting the command in authorized_keys on the spacewalk host to only return spacewalk-report data when the sst key is used. Version-Release number of selected component (if applicable): 0.19 How reproducible: every time Steps to Reproduce: 1. log into SAM host, cat /etc/splice/checkin.conf 2. use values under "spacewalk" section of config to obtain a shell on spacewalk host Actual results: user is logged in with a shell Expected results: user gets report data returned and session quits, no shell Additional info: There are a few ways to solve this problem, authorized_keys is just one of them. If this style of fix is used, the sst code and user setup doc need to be updated.
I think this can be solved with just documentation. I updated the user doc with the following text: For added security, restrict the user that logins with the ssh key to only running the spacewalk-report command. Do this by prepending the following to the key content in /root/.ssh/authorized_keys: command="/usr/bin/spacewalk-report $SSH_ORIGINAL_COMMAND" Added to line 75 in http://splice.pad.engineering.redhat.com/46 Going this route doesn't require any changes to sst.
actually, I had to change sst to no longer specify to run the /usr/bin/spacewalk-report command since it's now confined to run that command in the authorized_keys file on the satellite server. commit aba924a3a65e0a7e60ee5d72ce5e2232cdff1546
Verified in spacewalk-splice-tool-0.24-1.el6sam.x86_64 However /etc/splice/checkin.conf still has spacewalk_reports=/usr/bin/spacewalk-report setting which is useless after the hardening (the setting is in ~/.ssh/authorized_keys now)
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHEA-2013-1390.html