Bug 1258726 - virt-who can't run libvirt remote mode and show the permission denied error
virt-who can't run libvirt remote mode and show the permission denied error
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: virt-who (Show other bugs)
7.2
x86_64 Linux
high Severity high
: rc
: ---
Assigned To: Radek Novacek
Li Bin Liu
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-09-01 02:18 EDT by Eko
Modified: 2016-11-30 19:36 EST (History)
6 users (show)

See Also:
Fixed In Version: virt-who-0.14-7.el7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-11-19 06:58:01 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Eko 2015-09-01 02:18:51 EDT
Description of problem:
config virt-who running remote libvirt mode, there is an permission denied issue and can't get or update the host/guests mapping info to server

Version-Release number of selected component (if applicable):
 - subscription-manager-1.15.9-6.el7.x86_64
 - python-rhsm-1.15.4-2.el7.x86_64
 - virt-who-0.14-4.el7.noarch

How reproducible:
always

Steps to Reproduce:
1. config virt-who running remote libvirt mode:
# grep -E -v '(^#|^$)'  /etc/sysconfig/virt-who
VIRTWHO_DEBUG=1
VIRTWHO_LIBVIRT=1
VIRTWHO_LIBVIRT_OWNER=7659635
VIRTWHO_LIBVIRT_ENV=7659635
VIRTWHO_LIBVIRT_SERVER=10.66.128.13
VIRTWHO_LIBVIRT_USERNAME=root
VIRTWHO_LIBVIRT_PASSWORD=redhat


2. restart virt-who service and check the rhsm.log
2015-09-01 14:15:29,340 [INFO]  @libvirtd.py:105 - Protocol is not specified in libvirt url, using qemu+ssh://
2015-09-01 14:15:29,340 [INFO]  @libvirtd.py:116 - Libvirt path is not specified in the url, using /system
2015-09-01 14:15:29,340 [INFO]  @libvirtd.py:137 - Using libvirt url: qemu+ssh://root@10.66.128.13/system?no_tty=1
2015-09-01 14:15:29,426 [ERROR]  @libvirtd.py:145 - Error in libvirt backend
Traceback (most recent call last):
  File "/usr/share/virt-who/virt/libvirtd/libvirtd.py", line 141, in _connect
    v = libvirt.openAuth(url, auth, libvirt.VIR_CONNECT_RO)
  File "/usr/lib64/python2.7/site-packages/libvirt.py", line 105, in openAuth
    if ret is None:raise libvirtError('virConnectOpenAuth() failed')
libvirtError: Cannot recv data: Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).: Connection reset by peer
2015-09-01 14:15:29,426 [ERROR]  @virt.py:302 - Virt backend 'env/cmdline' fails with error: Cannot recv data: Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).: Connection reset by peer


Actual results:
[ERROR]  @virt.py:302 - Virt backend 'env/cmdline' fails with error: Cannot recv data: Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).: Connection reset by peer


Expected results:
virt-who can run normally when config to remote libvirt mode

Additional info:
Comment 1 Radek Novacek 2015-09-01 02:25:41 EDT
Password authentication with remote libvirt might not work at the moment. Can you please try to copy your public ssh key to the remote system:

ssh-copy-id root@10.66.128.13

Let me know if that helps. In the meanwhile I'll try to fix the password authentication or at least document it.
Comment 3 Eko 2015-09-01 02:59:50 EDT
hi radek, 
If I create the public ssh key and make ssh to login the remote libvirt host without password, thus, virt-who can run normally.
Comment 4 Radek Novacek 2015-09-01 04:29:52 EDT
ssh transport in libvirt doesn't support password authentication without ssh-agent. I'll add a note that this is not supported and the user should use ssh keys.
Comment 5 Radek Novacek 2015-09-01 06:41:56 EDT
Fixed in virt-who-0.14-7.el7.
Comment 7 Eko 2015-09-07 06:00:51 EDT
hi radek, how to verify this issue on virt-who-0.14-7.el7.noarch?
when I run virt-who service for libvirt remote mode with password, there is no any note or warning message found.

I think it should be more best if virt-who can support "ssh password" and "ssh key" both.
Comment 8 Radek Novacek 2015-09-08 04:29:47 EDT
When you supply --libvirt-password option, virt-who should show a warning (Password authentication doesn't work with ssh transport on libvirt backend, copy your public ssh key to the remote machine).

There is also a note in virt-who(8) manual page.

I agree that it would be better to support "ssh passwords", but libvirt doesn't support supplying passwords directly and it depends on usage of ssh-agent. Unfortunately we can't use ssh-agent from virt-who.
Comment 9 Eko 2015-09-08 06:05:56 EDT
ok, got it, I will change the status to verify
Comment 10 errata-xmlrpc 2015-11-19 06:58:01 EST
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-2370.html
Comment 13 Radek Novacek 2016-11-24 01:11:19 EST
Waldirio,

yes, you need to copy public ssh keys to remote servers, as noted in the virt-who man page:

       --libvirt-password=PASSWORD
              Password for connecting to libvirt. This option doesn't work with ssh transport (default), copy your public ssh key to the remote machine.

Does this solve your problem?
Comment 14 Waldirio M Pinheiro 2016-11-24 06:15:07 EST
Hi Radek, good morning

For now yes, although customer sent to us one great attention point related to security, actually if anyone get access to this server, will be possible to do / access all computer nodes as root and on their environment, this is one huge security issue.

Do you believe be possible improve the code to use the password defined in virt-who conf files ?! There we can just define the remote password in crypt format.

Appreciate your feedback.


Best Regards
-- 
Waldirio M Pinheiro | Senior Software Maintenance Engineer

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