Hide Forgot
Description of problem: Running the rhc-chk command can inaccurately report SSH test failures in the case where a user has overridden SSH configuration in ~/.ssh/config. Version-Release number of selected component (if applicable): All client tool versions How reproducible: 100% Steps to Reproduce: 1. Create a new user / domain - user1 / user1domain 2. Create a new application with that user. 3. Create a new SSH key using ssh-keygen and call it demo_rsa 4. Upload that new key via the web console 5. Change ~/.ssh/config to add a specific entry for this domain that matches the new domain and uses the demo_rsa key Host *-user1domain.rhcloud.com IdentityFile ~/.ssh/demo_rsa VerifyHostKeyDNS yes StrictHostKeyChecking no UserKnownHostsFile ~/.ssh/libra_known_hosts 6. Verify that 'git push' to your application still works. 7. Run rhc-chk for the new user Actual results: Two failures are reported on the SSH connectivity because the key is compared with libra_rsa_id, not the key that is used in ~/.ssh/config. Expected results: No rhc-chk failures. Additional info:
Fotios: Not sure if anything changed recently, but I have tested this thoroughly using the CLI tools alone (not uploading keys using the web console) and this test case works. A couple of sprints back when I added the multiple ssh key functionality to the CLI tools, I modified the rhc-chk command to take into consideration the primary as well as any additional keys.
Matt and I discussed this before and this will fail, but the user wouldn't even know because git/ssh will still work. Our tests/tools only take into account a libra_rsa key or something specified in ~/.openshift/express.conf. But ssh will also parse the ~/.ssh/config and pull the correct key.
Can we make a decision for this one for this release? If we're going to make a change lets make it, otherwise close as not a bug.
This has been converted into US2356 and will be completed in a future sprint.