2

I am using rhc cli tool for OpenShift projects and have encountered a problem with default rhc ssh key.

On any ssh related action (setup, app-create, etc..) rhc creates ~/.ssh/id_rsa key if it does not exist. I do not like that behaviour, and I would like it to use something like ~/.ssh/my_openshift key.

I have added ssh_key_file='~/.ssh/my_openshift' to the ~/.ssh/express.conf, but it does not help.

So, the question is;

  • how I can configure rhc tool to use custom ssh-key?

Note: I know how to add additional ssh key, but I would like to stop rhc creating/using ~/.ssh/id_rsa

UPDATE 1

Unfortunately King-Wizard (deleted) answer did not answer my question because:

  1. Answer does not figure - is it possible or not to make rhc ignore the ~/.ssh/id_rsa during setup.

  2. In my opinion, the main problem - if we are using several apps that requires default ssh key (id_rsa), that will add mess in controlling of ssh keys.

  3. Temporary fix, that I have found, is creating an empty id_rsa file and blocking write access to it. So:

    • Nothing can use id_rsa correctly - this is how we will catch apps with unhealthy attempt to use id_rsa. And it is good for me, because I do not use id_rsa key at all.
    • rhc sees that id_rsa exists, and do not try to create its own during rhc setup.
    • rhc cannot use id_rsa, so it uses additional keys added via rhc sshkey add somekey_

  4. My solution is not the best, because it also create mess, but less than shifting keys with bash commands. In my opinion, Better solutions are:

    • Check if original rhc supports custom default keys through express.conf
    • If original rhc doesn't supports that, fix and send patch to the community =)
Community
  • 1
  • 1
AlexMakII
  • 43
  • 5

1 Answers1

0

First I can't understand why don't you want to have a default ssh key. But anyway, please review my answer here: https://stackoverflow.com/a/34559668/520567

SSH key is used for ssh. Token is used for API requests. These are different use cases. rhc uses the ssh executable underneath so using a custom key means to edit ~/.ssh/config to set your default key to another location or set different keys for different hosts. This is not handled well by rhc setup. But once you have your key set, you don't have to run rhc setup anymore.

Too long to explain everything without specific "what" and "why" are you trying to do it that way.

Community
  • 1
  • 1
akostadinov
  • 17,364
  • 6
  • 77
  • 85
  • Why not id_rsa: 1. If two apps requires id_rsa (And its possible) at the same time - we got problems. So we'll be forced to use one key for two different apps (dummy example: OpenShift, Amazon, Github). 2. I dont like idea to use default ssh key for 3rd part APIs. IMHO id_rsa could be used for intranet, IOT or something like network of straight chained servers. As an example: it's like usage of main email for lame services - it's ok to use main email for linkedin/stackoverflow as personal identity, but not for stupid-game-for-2-hours.com. – AlexMakII Jan 04 '16 at 15:17
  • There is one more problem with rhc, and it was the main reason for my question. If we'll omit problem with rhc setup (that happens only once), rhc still refer to id_rsa on other action (eg: rhc app-create), and if key missed, rhc will create it. So, I'm not sure in this tool, and cand be sure that it will not be chained to id_rsa in a wrong way or unpredictable situation. – AlexMakII Jan 04 '16 at 15:33
  • @AlexMakII, could you show a log with this behaviour? Also your `rhc` version. If latest `rhc` creates ssh keys outside `rhc setup` this would really be a bug worth reporting. Thank you. – akostadinov Jan 04 '16 at 16:39
  • wrt your id_rsa usage, I believe it's completely different. Your public key (id_rsa.pub) cannot be used to reach you like your email address or to access any resource like with your password. It only serves to verify that a person using the corresponding private key (id_rsa) is at the other end. `id_rsa` is never exposed to the endpoint, it only signs some verification messages. So you gain nothing by having multiple keys except inconvenience to select correct one each and every time. I can't remember any security guy recommending multiple ssh keys usage.. just saying – akostadinov Jan 04 '16 at 16:49
  • btw in all three examples above the ssh key is only used for actual ssh connections and other auth is used for API calls. In the github example the key is used to access repos over the `git+ssh` protocol. If you try to use git over `https`, then you'll see ssh key does not help you. – akostadinov Jan 04 '16 at 16:53
  • multiple keys - yep, you are almost right, but IMO one key per PC is a point of failure, especially if it's personal PC hat is chained to multiple diverse services. – AlexMakII Jan 07 '16 at 20:32
  • About auto-creation of id_rsa on non-setup actions. My rhc is 1.38.4. I've removed id_rsa, called 'rhc app-create someapp python-2.7' and during app creation got 'No SSH keys were found. We will generate a pair of keys for you.'. And id_rsa is generated. So, right now, till I'm rethinking current situation - my choose is empty id_rsa + chmod 000. But thank you anyway, your mentions are helpful on my way. Cheers – AlexMakII Jan 07 '16 at 20:39
  • @AlexMakII, I could reproduce and I filed a bug for it https://bugzilla.redhat.com/show_bug.cgi?id=1296994 ; wrt "one key per PC is a point of failure" as I wrote already, I see no reasoning for that. Perhaps you can explain how does it matter? – akostadinov Jan 08 '16 at 16:31
  • Although using 1 key per host is no more secure than using a shared key, using mult. keys provides risk management benefits - if shared key is compromised then the attacker gains access to all systems vs. only the one system if using multiple keys. As http://security.stackexchange.com/questions/40050/what-is-the-best-practice-separate-ssh-key-per-host-and-user-vs-one-ssh-key-for points out it does mitigate risk of attack impact even if not inherently more secure & per GitHub it's not just best practice: sharing keys violates their TOS https://developer.github.com/guides/managing-deploy-keys/ – Bryan 'BJ' Hoffpauir Jr. May 22 '16 at 05:20
  • @Bryan'BJ'Hoffpauir, I think you're mixing two things. Sharing keys **between users** is stupid and nobody advocates that. Sharing same user private key across multiple machines - not sure. If you have two personal keys which allow access to same services, then losing either of them to an attacker is equally bad - e.g. you save yourself nothing. Now depending on particular usage it may make some sense. But having 5 keys on same machine, same user for 5 services gives you basically nothing. If attacker can grab one, then he can grab all the keys. I don't see linked answer contradicting. – akostadinov May 23 '16 at 22:19