Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1510536 - [RFE] obfuscate password for ssh key in virt-who config file used to connect to hypervisor [NEEDINFO]
Summary: [RFE] obfuscate password for ssh key in virt-who config file used to connect ...
Keywords:
Status: NEW
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: virt-who
Version: 7.4
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: pre-dev-freeze
: ---
Assignee: candlepin-bugs
QA Contact: Eko
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-11-07 15:57 UTC by Andrea Perotti
Modified: 2018-11-08 00:05 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Target Upstream Version:
aperotti: needinfo? (candlepin-bugs)
dconsoli: needinfo? (candlepin-bugs)


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Bugzilla 1510631 None NEW [RFE] Virt-who SSH private key in a configurable location 2019-03-28 21:48:07 UTC

Internal Links: 1510631

Description Andrea Perotti 2017-11-07 15:57:01 UTC
Description of problem:

2. What is the nature and description of the request?
Customer would like to use an ssh key protected with passphrase in virt-who, and having that password obfuscated in the virt-who configuration file.

3. Why does the customer need this? (List the business requirements here)
Compliance requires that each used ssh keys mush be protected with password 

4. How would the customer like to achieve this? (List the functional requirements here)
With the addition of a new option in virt-who config file

5. For each functional requirement listed in question 4, specify how Red Hat and Customer can test to confirm the requirement is successfully implemented.

You should be able to use virt-who config with an encrypted ssh key, with obfuscated password 

6. Is there already an existing RFE upstream or in Red Hat bugzilla?
   No

7. How quickly does this need resolved? (desired target release)
As soon as possible, it should be made available both on RHEL6 and RHEL7

8. Does this request meet the RHEL Inclusion criteria (please review)
  Yes
9. List the affected packages
virt-who

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

virt-who-0.19-6

Comment 2 Craig Donnelly 2017-11-07 18:26:49 UTC
Hello,

I wanted to clarify what it is exactly you were looking for in this request.

My interpretation of what you have laid out is as follows:

You have a system that is using libvirt which virt-who would be connecting to via SSH w/username + password - and you want the password to not be plain text.

If that is correct, is the requirement not met by utilizing 'virt-who-password' which ships with virt-who to encrypt the password by way of hashing?

Please provide a little more detail in explicitly what it is your aiming for if the above is not a resolution.

Thanks!

Comment 3 Andrea Perotti 2017-11-07 20:48:40 UTC
Hi,
   the request is for a more complex use case.

Scenario here is that you do connect to libvirt via ssh, but you do use: 

username
ssh-key (id_rsa+id_rsa.pub)

and that ssh-key is password protected.

Using virt-who-password is fine to scramble, is just needed to have a way to express which is the passphrase of the ssh-key in a non plain-text way.

If you have further doubt on the request, please just let me know.

Comment 4 Craig Donnelly 2017-11-07 22:17:50 UTC
So what I understand based off of that is that you want 'virt-who' daemon to be able to use an ssh-key to login to libvirt and pass an encrypted password to unlock the ssh-key.

In this case, I would call this an RFE for virt-who, which would need to be placed under RHEL for that team.

I will shift this to the correct place.


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