Red Hat Bugzilla – Bug 841033
If a pre-existing user creates a new account, the CLI doesn't know the libra_rsa_id key is invalid
Last modified: 2015-05-14 22:00:34 EDT
Description of problem:
a preexisting user with a pre-existing ssh key trys to use the CLI with a new account ( a new openshift account) and CLI sees the old libra_rsa_id there and so it doesn't complain, overwrite, or overwrite. So the user thinks things are fine but actually none of the SSH commands work.
Running "rhc setup" does not fix it
The error in "rhc domain status" doesn't really say how to fix it
Basically, creating an app fails with a bad ssh key error message and the user is then stuck.
Steps to Reproduce:
1. Have an existing account in OpenShift and set up the Command line tools with that account
2. Create a new account and then create the domain for this new account in the web console
3. Now if you try to use that new account with the command line tools the ssh keys won't be right
Couple of things we should be doing - 1, trying to validate the SSH session with your account from rhc setup. This might be something we need to enable in broker (a test ssh endpoint, perhaps). The rhc setup should validate that at least one of the user's public keys are located on the remote server.
I attempted to reproduce the issue, but did not run into any problems.
Let me explain what I did:
1. Completely removed my ~/.openshift directory
2. Ran 'rhc setup' with my standard openshift account (which has all of my .ssh keys associated with it)
3. Went to www.openshift.com, created a completely new account, and set up the domain ID but nothing else.
4. Back in my CLI, I re-ran 'rhc setup', and provided the new account ID
- 'rhc setup' moved my existing ~/.openshift/express.conf file to ~/.openshift/express.conf.bak
- 'rhc setup' noted that I didn't have an associated key and did the following:
Your public ssh key must be uploaded to the OpenShift server. Would you like us to upload it for you? (yes/no) yes
You can enter a name for your key, or leave it blank to use the default name. Using the same name as an existing key will overwrite the old key.
Since you do not have any keys associated with your OpenShift account, your new key will be uploaded as the default key
Sending new key default .. Success
The only thing that I did in the above exchange was to answer 'yes' to the first question.
After 'rhc setup' completed, I attempted to create a new application under that account:
rhc app create -a foobar -t php-5.3
This was successful.
Similarly, editing files and using 'git push' with this application was also successful.
Can you please correct my test process or provide me with more information on how to reproduce this issue?
Hey Harrison. Can you please use a different key than the default that is created in your other account. For example: Your first account should use a non-rhc generated key. Assume the user had a pre-existing key and associated this with the first account.
It is also possible that with the new changes to the RHC tool we have fixed this issue.
If we can't reproduce for now please don't close just put it to a really low priority until I do a few more shows and see if it pops up.
Thanks for the quick response; I'll try it with your suggestions before I make any changes to this record.
I tried to reproduce the bug as suggested by Steve (see comment 4), but still could not trigger the described behavior. I am lowering severity and priority to low and will await additional information.
The issue is the old tools would write to .ssh/config however id_rsa should always default if it tries and fails with the libra keys. I also think this only effects devenv users though really old versions of rhc may have also done this.
I revisited this today with rhc version 0.98.16. The system no always falls back to id_rsa now, and will offer to create and upload this file if it doesn't exist. Therefore, if account #1 is using a non-standard key file, the second account's run through 'rhc setup' will include the prompts to set up this new key.
Based on this version of the code, I think that the behavior of the client in this regard is robust enough to handle most common use cases. A user would need to specifically create situations wherein the current logic was insufficient.
Let me know if you would like to keep this issue open, otherwise I will close it tomorrow.
Closing as "fixed indirectly".