Bug 1330475

Summary: Should let user to input password when add another server in cockpit
Product: [oVirt] ovirt-node Reporter: wanghui <huiwa>
Component: UIAssignee: Douglas Schilling Landgraf <dougsland>
Status: CLOSED NOTABUG QA Contact: wanghui <huiwa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 4.0CC: bugs, cshao, fdeutsch, huiwa, huzhao, leiwang, stefw, weiwang, yaniwang
Target Milestone: ovirt-4.0.0-betaFlags: fdeutsch: ovirt-4.0.0?
rule-engine: planning_ack?
rule-engine: devel_ack?
rule-engine: testing_ack?
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-05-05 11:27:41 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Node RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1140646    
Attachments:
Description Flags
Screenshot for adding server none

Description wanghui 2016-04-26 10:16:24 UTC
Created attachment 1150835 [details]
Screenshot for adding server

Description of problem:
It should let user to input password when add another server in cockpit. In node4.0, the serverA can be added to serverB's cockpit without the password. And then serverA can be managed by serverB's cockpit. It's insecure that serverA can be managed just by providing the ip address. 

Version-Release number of selected component (if applicable):
ovirt-node-ng-installer-ovirt-3.6-2016042500.iso 
cockpit-0.103-1.el7.centos.x86_64
cockpit-ovirt-0.5.1-0.0.master.el7.centos.noarch

How reproducible:
100%

Steps to Reproduce:
1. Anaconda install NGN 4.0.
2. Start cockpit service.
3. In dashboard tab, add another server with ip address which is a node 4.0.

Actual results:
1. After step3, the another node 4.0 can be added without require a password.

Expected results:
1. It should require the root password while been added.

Additional info:
1. If we added a fedora 23 host to cockpit, it will require a root password.

Comment 1 Fabian Deutsch 2016-04-26 11:34:49 UTC
That is weird.

Did you maybe do an ssh key exchange between the servers?

Comment 2 wanghui 2016-04-27 05:23:07 UTC
(In reply to Fabian Deutsch from comment #1)
> That is weird.
> 
> Did you maybe do an ssh key exchange between the servers?

No. I just install another Node 4.0, and added to serverA.

Comment 3 Fabian Deutsch 2016-04-27 07:17:42 UTC
Can you somehow verify that you can really access the dashbaord of the other server and retrieve informations?

Stef, any thoughts on this one?

Comment 4 Stef Walter 2016-04-27 08:48:26 UTC
Need a reproducer for this. Perhaps a cluster of VMs we can access. 

Cockpit doesn't do magic authentication. The credentials for the remaining node are the same as were used to log into cockpit. Click on the name in the upper left corner, and choose 'Authentication' from the menu to see the credentials that Cockpit has in the session available to access other servers.

Comment 5 Sandro Bonazzola 2016-05-02 09:49:21 UTC
Moving from 4.0 alpha to 4.0 beta since 4.0 alpha has been already released and bug is not ON_QA.

Comment 9 Stef Walter 2016-05-04 13:31:17 UTC
This behavior is intentional. After changing the password on Host2, and logging out and logging back in we get the following behavior.

 1. Attempts to access host2 result in a screen that says
    "Couldn't connect to the machine" and "Login failed"

 2. A "Troubleshoot" button is displayed.

 3. Clicking the "Troubleshoot" button offers the following message: 
 
    "Cockpit was unable to log into 10.66.8.112 you can change your
     authentication credentials below. You may prefer to synchronize users."

 4. Typing a password here allows access to Host2

 5. Choosing the 'synchronize users' link allows one to synchronize passwords
    so that the user does not run into this problem again.

Does this match the behavior you've experienced? If so this should be marked as WONTFIX.

In addition, the best practice is that the admin uses SSH keys to access the machines in question and not passwords. When SSH keys are available to root on Host1 they can be used to access Host2.

Comment 10 wanghui 2016-05-05 03:00:41 UTC
Yes, this matched the behavior. Thanks!