Red Hat Bugzilla – Bug 1128156
ssh AuthorizedKeyFiles are assumed to be in $HOME/.ssh/authorized_keys ignoring any configuration from /etc/ssh/sshd_config
Last modified: 2015-05-13 13:52:58 EDT
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:
Please add doc text for this known issue.
Please review the edited doc text and sign-off.
Upstream patch sent. http://review.gluster.org/#/c/9436/
Downstream patch sent. https://code.engineering.redhat.com/gerrit/#/c/42148/
Tested the fix on the build 3.6.0.46-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.
Tested and verified the fix on the build 3.6.0.47-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.
Created attachment 995993 [details] Detailed logs
Hi Aravinda, The doc text is updated. review the same and sign off if it looks ok.
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