Bug 1025810 - [Admin Portal] Host re-install after previous installation failure offers SSH key auth access although SSH public key doesn't exist on the host
[Admin Portal] Host re-install after previous installation failure offers SSH...
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine-webadmin-portal (Show other bugs)
3.3.0
Unspecified Unspecified
unspecified Severity high
: ---
: 3.4.0
Assigned To: Yaniv Bronhaim
sefi litmanovich
infra
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-11-01 12:09 EDT by Jiri Belka
Modified: 2016-02-10 14:32 EST (History)
10 users (show)

See Also:
Fixed In Version: ovirt-3.4.0-alpha1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Infra
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
engine.log (69.40 KB, application/x-gzip)
2013-11-01 12:09 EDT, Jiri Belka
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 22919 None None None Never

  None (edit)
Description Jiri Belka 2013-11-01 12:09:55 EDT
Created attachment 818349 [details]
engine.log

Description of problem:

If host installation fails very early, then during next host re-installation UI offers a dialog where default is to use SSH key auth while connecting to host and executing re-installation procedure.

Problem is that during previous installation failure public SSH key wasn't uploaded to the host, thus SSH connection with key auth fails.

2013-Nov-01, 16:57
	
Host dell-r210ii-13 installation failed. SSH authentication to 'root@10.34.62.205' failed. Please verify provided credentials. Make sure key is authorized at host.

Version-Release number of selected component (if applicable):
is21

How reproducible:
100%

Steps to Reproduce:
1. a host which has never been part of setup
2. iptables -I OUTPUT -p tcp --dport 80 -j REJECT # to block access to repos
3. add the host into setup (this will obviously fail as rpm packages could not be installed)
4. iptables -D OUTPUT -p tcp --dport -j REJECT # remove previous fw rule
5. re-add/re-install the host from RHEVM ui

Actual results:
dialog shows ssh access via key auth as default, clicking 'OK' and then there's login failure into the host

Expected results:
if rhevm ui is not sure the ssh public key was uploaded to the host and it is there, it should not offer such authentication; thus offer just password auth.

Additional info:
Comment 1 Barak 2013-11-03 07:38:48 EST
Yaniv can we change the default access for this specific case where the host is in status "Install Failed" ?
Comment 2 Yaniv Bronhaim 2013-11-03 09:34:23 EST
Of-course we can.. will do
Comment 3 sefi litmanovich 2014-02-17 04:59:17 EST
reproduced and verified on ovirt-3.4.0-0.7.beta2.

after installation failled due to non connectivity, tried to re-install.
default option was set to password authentication as requested.
ssh public key authorization is still a possible option which appears in menu and wasn't disabled completely.
If this is the expected and wanted result then I can verify.
Comment 4 sefi litmanovich 2014-02-17 05:13:41 EST
Verified after talking with ybronheim. got the expected result - password authenctication is the default and ssh public key authentication option is possible in case user chooses to set it manually on host e.g.
Comment 5 Yaniv Bronhaim 2014-02-17 06:15:13 EST
although the reporter wrote : "Expected results:
if rhevm ui is not sure the ssh public key was uploaded to the host and it is there, it should not offer such authentication; thus offer just password auth."

still it is possible to use the ssh PK authentication method by manually copy the key as in first additional of the host. this fix only changes the default option, so that clicking automatically OK won't fail the operation without user's intervention
Comment 6 Itamar Heim 2014-06-12 10:10:09 EDT
Closing as part of 3.4.0

Note You need to log in before you can comment on or make changes to this bug.