Bug 1248238 - RFE: Investigate using paramiko for spice+ssh, instead of manual ssh calls
Summary: RFE: Investigate using paramiko for spice+ssh, instead of manual ssh calls
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Virtualization Tools
Classification: Community
Component: virt-manager
Version: unspecified
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Cole Robinson
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-07-30 00:19 UTC by jamespharvey20
Modified: 2018-10-08 18:43 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2018-10-08 18:43:00 UTC
Embargoed:


Attachments (Terms of Use)

Description jamespharvey20 2015-07-30 00:19:02 UTC
Description of problem:

When I connect to a remote QEMU/KVM in virt-manager, it asks me for my user password.  I enter it, and it accepts it.

I open a running virtual machine's remote console, it first shows "Connecting to graphical console for guest".  And, asks me for my password again.

Then, the VM's console area goes black, and it asks me for my password again.  (But it won't let me type for about 10 seconds.)

Then it asks me for my password again.

And again.

Then it shows the VM's console with correct content.  And, asks me for my password again.

Then it asks me for my password again.

Then, I can use the VM.

(No, there's no editing mistake here.  I have to type my password 7 times.)



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

virt-manager source build from git.  v1.2.1.r4564.466bf92-1 (master, at least as of a short while ago).  This happened identically on v1.2.1-release.

libvirt 1.2.17 (-2 Arch)

openbsd-netcat 1.105_7 (-7 Arch)

polkit 0.112 (-4 Arch)

openssh 6.9p1 (-2 Arch)

Yeah, both of these are Arch systems using kernel 4.1.3 (-1 Arch)

I'm starting here, knowing this may not actually be a virt-manager issue.  Not sure how to diagnose who is behind this further, but willing to run commands/tests you give me.


How reproducible:
Completely

Steps to Reproduce:
1. polkit authentication.  gpasswd -a username kvm.  re-log.  /etc/polkit-1/rules.d/49-org.libvirt.unix.manager.rules:
polkit.addRule(function(action, subject) {
   if (action.id == "org.libvirt.unix.manage" &&
      subject.isInGroup("kvm")) {
         return polkit.Result.YES;
   }
});
2. virt-manager to connect to remote hypervisor (QEMU/KVM) via ssh, my username - not root.

Actual results:
7 password prompts

Expected results:
1 password prompt.  Maybe none using the autoconnect feature.

Comment 1 jamespharvey20 2015-08-09 03:45:41 UTC
Any thoughts?  Things I should run to help diagnose this?

Comment 2 Cole Robinson 2015-08-09 18:20:43 UTC
The multiple password prompts are likely due to spice: spice opens multiple network connections for its various channels (video, input, sound, usb redirection, etc), and each need to open an ssh tunnel to the remote machine. So you'll get lots of password prompts

The simplest 'fix' is to either setup ssh keys so you only need to auth once for SSH.

Polkit doesn't help here, since polkit config won't let you skip an ssh prompt no matter how you configure it AFAIK

I have some ideas about maybe simplifying this in the future, like trying to use an ssh library rather than forking the 'ssh' which has its own set of problems, but it's just handwavy future work.

Comment 3 Cole Robinson 2018-10-08 18:43:00 UTC
So I've looked into this. Using paramiko or another SSH library would help in some ways: we could do away with the multiple password prompts, and drop some of the complexity with serializing connection opening. That said, to get full coverage we would need to use libvirt's libssh/libssh2 transport, which isn't guaranteed to be available, and paramiko isn't available on all distros we care about, so the transition would be rough.

I don't think it's worth reworking our battle tested code in virt-manager for something that's simpler but potentially has its own set of problems. Plus really the recommendation for all SSH connections is really 'just use ssh keys' which side steps all these issues entirely.


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