Description of problem: only leave the id_rsa file in ~/.ssh, then run rhc setup when check ssh-key, it shouldn't show exception, it should point out key not found and generate new pair key. if remove all ~/.ssh folder,do rhc setup works well. if remove all files in ~/.ssh ,do rhc setup works well. if only remove ~/.ssh/id.rsa,do rhc setup works well. Version-Release number of selected component (if applicable): fork_ami_US2597_US2599_US2813_US2817_US2872_172 How reproducible: always Steps to Reproduce: 1.run rhc setup to generate a pair key in ~/.ssh 2.remove the ~/.ssh/id_rsa.pub 3.run rhc setup again Actual results: [qgong@localhost ~]$ rm -rf .ssh/id_rsa.pub [qgong@localhost ~]$ rhc setup Starting Interactive Setup for OpenShift's command line interface We'll help get you setup with just a couple of questions. You can skip this in the future by copying your config's around: /home/qgong/.openshift/express.conf /home/qgong/.ssh/ To connect to ec2-107-21-153-249.compute-1.amazonaws.com enter your OpenShift login (email or Red Hat login id): |qgong| Password: Configuration file /home/qgong/.openshift/express.conf already exists, backing up to /home/qgong/.openshift/express.conf.bak Created local config file: /home/qgong/.openshift/express.conf The express.conf file contains user configuration, and can be transferred to different computers. /usr/lib/ruby/gems/1.8/gems/net-ssh-2.5.2/lib/net/ssh/key_factory.rb:87:in `read': No such file or directory - /home/qgong/.ssh/id_rsa.pub (Errno::ENOENT) from /usr/lib/ruby/gems/1.8/gems/net-ssh-2.5.2/lib/net/ssh/key_factory.rb:87:in `load_public_key' from /usr/lib/ruby/gems/1.8/gems/rhc-0.99.3/lib/rhc/ssh_key_helpers.rb:87:in `fingerprint_for_local_key' from /usr/lib/ruby/gems/1.8/gems/rhc-0.99.3/lib/rhc/ssh_key_helpers.rb:99:in `fingerprint_for_default_key' from /usr/lib/ruby/gems/1.8/gems/rhc-0.99.3/lib/rhc/wizard.rb:142:in `ssh_key_uploaded?' from /usr/lib/ruby/gems/1.8/gems/rhc-0.99.3/lib/rhc/rest.rb:133:in `any?' from /usr/lib/ruby/gems/1.8/gems/rhc-0.99.3/lib/rhc/wizard.rb:142:in `each' from /usr/lib/ruby/gems/1.8/gems/rhc-0.99.3/lib/rhc/wizard.rb:142:in `any?' from /usr/lib/ruby/gems/1.8/gems/rhc-0.99.3/lib/rhc/wizard.rb:142:in `ssh_key_uploaded?' from /usr/lib/ruby/gems/1.8/gems/rhc-0.99.3/lib/rhc/wizard.rb:214:in `upload_ssh_key_stage' from /usr/lib/ruby/gems/1.8/gems/rhc-0.99.3/lib/rhc/wizard.rb:48:in `send' from /usr/lib/ruby/gems/1.8/gems/rhc-0.99.3/lib/rhc/wizard.rb:48:in `run' from /usr/lib/ruby/gems/1.8/gems/rhc-0.99.3/lib/rhc/wizard.rb:46:in `each' from /usr/lib/ruby/gems/1.8/gems/rhc-0.99.3/lib/rhc/wizard.rb:46:in `run' from /usr/lib/ruby/gems/1.8/gems/rhc-0.99.3/lib/rhc/commands/setup.rb:11:in `run' from /usr/lib/ruby/gems/1.8/gems/rhc-0.99.3/lib/rhc/commands.rb:103:in `send' from /usr/lib/ruby/gems/1.8/gems/rhc-0.99.3/lib/rhc/commands.rb:103:in `to_commander' from /usr/lib/ruby/gems/1.8/gems/commander-4.1.2/lib/commander/command.rb:180:in `call' from /usr/lib/ruby/gems/1.8/gems/commander-4.1.2/lib/commander/command.rb:180:in `call' from /usr/lib/ruby/gems/1.8/gems/commander-4.1.2/lib/commander/command.rb:155:in `run' from /usr/lib/ruby/gems/1.8/gems/commander-4.1.2/lib/commander/runner.rb:402:in `run_active_command' from /usr/lib/ruby/gems/1.8/gems/rhc-0.99.3/lib/rhc/command_runner.rb:30:in `run!' from /usr/lib/ruby/gems/1.8/gems/commander-4.1.2/lib/commander/delegates.rb:7:in `run!' from /usr/lib/ruby/gems/1.8/gems/rhc-0.99.3/lib/rhc/cli.rb:40:in `start' from /usr/lib/ruby/gems/1.8/gems/rhc-0.99.3/bin/rhc:57 from /usr/bin/rhc:19:in `load' from /usr/bin/rhc:19 Expected results: it should point out key not found and generate new pair key Additional info:
Hitherto, the assumption has been that if a private key exists, we assume that the SSH key is usable (i.e., it exists and is readable, and so on). This is a ticket that tests this assumption. I propose a fix here: https://github.com/BanzaiMan/rhc/commit/432f49aec6e88866deddc7ed4fb9573133cd9751 The above commit assumes: the absence of the public key means that the private key is unusable, therefore, we should proceed to regenerate an SSH key pair.
*** Bug 861527 has been marked as a duplicate of this bug. ***
I don't really want any complicated fixes for this since it is an artificial edge case. Simply catch the exception and let the user know there is an issue instead of having a traceback.
I'm closing this as 'NOTABUG', since this is a limited use case where most users should not encounter. If the user does encounter, it is most likely due to uninformed SSH key manipulation, and the stack trace give should be sufficient to troubleshoot.