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
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
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
ssh key based auth is correctly setup according to the local ssh config.
Please add doc text for this known issue.
Please review the edited doc text and sign-off.
Upstream patch sent.
Downstream patch sent.
Tested the fix on the build 18.104.22.168-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 22.214.171.124-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]
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.