Bug 1128156 - ssh AuthorizedKeyFiles are assumed to be in $HOME/.ssh/authorized_keys ignoring any configuration from /etc/ssh/sshd_config
Summary: ssh AuthorizedKeyFiles are assumed to be in $HOME/.ssh/authorized_keys ignori...
Alias: None
Product: Red Hat Gluster Storage
Classification: Red Hat
Component: geo-replication
Version: rhgs-3.0
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
: RHGS 3.0.4
Assignee: Aravinda VK
QA Contact: Sweta Anandpara
Depends On: 1186192
Blocks: 1087818 1181117 1182947
TreeView+ depends on / blocked
Reported: 2014-08-08 12:51 UTC by Stuart Auchterlonie
Modified: 2019-08-15 03:56 UTC (History)
10 users (show)

Fixed In Version: glusterfs-
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.
Clone Of:
: 1181117 (view as bug list)
Last Closed: 2015-03-26 06:34:26 UTC
Target Upstream Version:

Attachments (Terms of Use)
Detailed logs (83.15 KB, text/plain)
2015-02-27 11:19 UTC, Sweta Anandpara
no flags Details

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:0682 0 normal SHIPPED_LIVE Red Hat Storage 3.0 enhancement and bug fix update #4 2015-03-26 10:32:55 UTC

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:


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

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

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.

Comment 7 Aravinda VK 2015-02-18 05:45:31 UTC
Downstream patch sent.

Comment 8 Sweta Anandpara 2015-02-24 09:56:06 UTC
Tested the fix on the build

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

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.


Note You need to log in before you can comment on or make changes to this bug.