Bug 841033

Summary:	If a pre-existing user creates a new account, the CLI doesn't know the libra_rsa_id key is invalid
Product:	OKD	Reporter:	Steven Citron-Pousty <spousty>
Component:	oc	Assignee:	N. Harrison Ripps <hripps>
Status:	CLOSED CURRENTRELEASE	QA Contact:	libra bugs <libra-bugs>
Severity:	low	Docs Contact:
Priority:	low
Version:	2.x	CC:	hripps, johnp, mpatel
Target Milestone:	---	Keywords:	Triaged
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-10-26 15:20:43 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:

Description Steven Citron-Pousty 2012-07-17 23:14:39 UTC

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.


How reproducible:
very

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
  
Actual results:


Expected results:


Additional info:

Comment 1 Clayton Coleman 2012-07-18 15:15:20 UTC

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.

Comment 2 N. Harrison Ripps 2012-07-30 14:01:22 UTC

Taking.

Comment 3 N. Harrison Ripps 2012-07-30 15:37:43 UTC

Hi Steve--
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.
    
    Current Keys:
        None
    
    
    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?

Thanks,
Harrison

Comment 4 Steven Citron-Pousty 2012-07-30 16:28:28 UTC

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
Steve

Comment 5 N. Harrison Ripps 2012-07-30 16:30:21 UTC

Thanks for the quick response; I'll try it with your suggestions before I make any changes to this record.

Comment 6 N. Harrison Ripps 2012-07-30 17:06:49 UTC

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.

Comment 7 John (J5) Palmieri 2012-10-04 16:44:12 UTC

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.

Comment 8 N. Harrison Ripps 2012-10-23 17:54:49 UTC

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.

Comment 9 N. Harrison Ripps 2012-10-26 15:20:43 UTC

Closing as "fixed indirectly".