Bug 1128156

Summary: ssh AuthorizedKeyFiles are assumed to be in $HOME/.ssh/authorized_keys ignoring any configuration from /etc/ssh/sshd_config
Product: [Red Hat Storage] Red Hat Gluster Storage Reporter: Stuart Auchterlonie <sauchter>
Component: geo-replicationAssignee: Aravinda VK <avishwan>
Status: CLOSED ERRATA QA Contact: Sweta Anandpara <sanandpa>
Severity: high Docs Contact:
Priority: high    
Version: rhgs-3.0CC: aavati, annair, asrivast, avishwan, bmohanra, csaba, nlevinki, nsathyan, sanandpa, sharne
Target Milestone: ---Keywords: ZStream
Target Release: RHGS 3.0.4   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: glusterfs-3.6.0.46-1 Doc Type: Bug Fix
Doc Text:
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.
 Story Points: ---
Clone Of:
: 1181117 (view as bug list) Environment:
Last Closed: 2015-03-26 06:34:26 UTC 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:
Bug Depends On: 1186192    
Bug Blocks: 1087818, 1181117, 1182947    
Attachments:
Description Flags
Detailed logs none

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 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.
Comment 10 Sweta Anandpara 2015-02-27 11:16:09 UTC 
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.
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