|Summary:||ssh AuthorizedKeyFiles are assumed to be in $HOME/.ssh/authorized_keys ignoring any configuration from /etc/ssh/sshd_config|
|Product:||Red Hat Gluster Storage||Reporter:||Stuart Auchterlonie <sauchter>|
|Component:||geo-replication||Assignee:||Aravinda VK <avishwan>|
|Status:||CLOSED ERRATA||QA Contact:||Sweta Anandpara <sanandpa>|
|Version:||rhgs-3.0||CC:||aavati, annair, asrivast, avishwan, bmohanra, csaba, nlevinki, nsathyan, sanandpa, sharne|
|Target Release:||RHGS 3.0.4|
|Fixed In Version:||glusterfs-22.214.171.124-1||Doc Type:||Bug Fix|
Previously, while creating a geo-replication session the public keys were added to $HOME/.ssh/authorized_keys even though AuthorizedKeys file is configured to other location in /etc/ssh/sshd_config file. Due to this, Geo-replication failed to find the ssh keys and failed to establish session with slave. With this fix, while adding ssh public keys, geo-replication reads the sshd_config file and adds the public keys to correct file and a geo-replication session can be established with a custom SSH location.
|:||1181117 (view as bug list)||Environment:|
|Last Closed:||2015-03-26 06:34:26 UTC||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:||1186192|
|Bug Blocks:||1087818, 1181117, 1182947|
Description Stuart Auchterlonie 2014-08-08 12:51:44 UTC
Description of problem: RHS assumes that everyone has their sshd configured to have AuthorizedKeys in $HOME/.ssh/authorized_keys. If this is not the case, then operations will fail because ssh public keys do not get correctly setup correctly Version-Release number of selected component (if applicable): 3.0EA and also RHS-2.1 How reproducible: 100% Steps to Reproduce: 1. Configure ssh on the target machine to look for authorized_keys in a non standard location 2. Attempt to setup / perform operations that rely on working ssh key based authentication 3. Actual results: Product expects authorized_key file only in the standard location and doesn't correctly setup key based auth if it is in a non standard location Expected results: ssh key based auth is correctly setup according to the local ssh config. Additional info:
Comment 2 Shalaka 2014-08-19 06:41:14 UTC
Please add doc text for this known issue.
Comment 5 Shalaka 2014-09-20 09:42:04 UTC
Please review the edited doc text and sign-off.
Comment 6 Aravinda VK 2015-01-12 12:46:23 UTC
Upstream patch sent. http://review.gluster.org/#/c/9436/
Comment 7 Aravinda VK 2015-02-18 05:45:31 UTC
Downstream patch sent. https://code.engineering.redhat.com/gerrit/#/c/42148/
Comment 8 Sweta Anandpara 2015-02-24 09:56:06 UTC
Tested the fix on the build 126.96.36.199-1 The geo-rep setup lands up in a faulty state. Post debugging by the dev, this bug holds dependency on BZ 1194574. Blocked on this bug as of now, until 1194574 is fixed.
Comment 10 Sweta Anandpara 2015-02-27 11:16:09 UTC
Tested and verified the fix on the build 188.8.131.52-1 1. Had a 2*2 distribute replicate volume on the master and another 2*2 distribute-replicate volume on the slave. 2. Modified the /etc/ssh/sshd.config file's parameter 'AuthorizedKeysFile' to a custom location. // Also, uncomment that line 3. Restart sshd.. 'service sshd restart' 3. 'ssh-keygen' at the master 4. 'ssh-copy-id <slavenode>' at the master This will copy to the default location.. Manually copy the file (of the master) /root/.ssh/id_rsa.pub to the slave custom location. Set the permissions to 600 5. Try to do a ssh from master to the target slave and verify that it doesn't ask for a password. 6. Create a geo-rep session between master and slave and execute start 7. Verify that the geo-rep session is succeesfully established between master and slave Moving the bug to fixed in 3.0.4. Detailed logs are attached.
Comment 11 Sweta Anandpara 2015-02-27 11:19:14 UTC
Created attachment 995993 [details] Detailed logs
Comment 12 Bhavana 2015-03-23 20:05:34 UTC
Hi Aravinda, The doc text is updated. review the same and sign off if it looks ok.
Comment 15 errata-xmlrpc 2015-03-26 06:34:26 UTC
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. https://rhn.redhat.com/errata/RHBA-2015-0682.html