Bug 1790962
| Summary: | [RFE] Implement SSH password authentication for Xen and VMX over SSH. | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 9 | Reporter: | Fabien Dupont <fdupont> |
| Component: | virt-v2v | Assignee: | Virtualization Maintenance <virt-maint> |
| Status: | CLOSED DUPLICATE | QA Contact: | Vera <vwu> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 9.0 | CC: | jsuchane, lersek, mxie, mzhan, ptoscano, rjones, tyan, tzheng, xiaodwan |
| Target Milestone: | beta | Keywords: | FutureFeature, Reopened, Triaged |
| Target Release: | --- | Flags: | pm-rhel:
mirror+
|
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | V2V | ||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2022-04-12 12:24:08 UTC | Type: | Feature Request |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
This is already implemented upstream, so it would be a backport: https://github.com/libguestfs/libguestfs/commit/4ad6e184a96a40278f7de9db07517903841f0fdd I had a go at backporting this and it's pretty rough. It requires the whole nbdkit series that was implemented here: https://www.redhat.com/archives/libguestfs/2019-July/msg00200.html (You can see that the patch we need is in fact the very last commit in that sequence, but it really does depend on all the others). I myself and quite happy with that series, although it was a bit controversial at the time. But it's a large upstream change and my feeling here is it would be better to wait for a rebase. Let's see what Pino thinks. (In reply to Richard W.M. Jones from comment #2) > I had a go at backporting this and it's pretty rough. It requires the whole > nbdkit series that was implemented here: > > https://www.redhat.com/archives/libguestfs/2019-July/msg00200.html > > (You can see that the patch we need is in fact the very last commit > in that sequence, but it really does depend on all the others). > > I myself and quite happy with that series, although it was a bit > controversial at the time. But it's a large upstream change and my > feeling here is it would be better to wait for a rebase. From my POV, this patch series changes too many things, and TBH it was pushed upstream with almost no review [*]. Even assuming it was done now, there is not much time left before the next AV release (8.2.0) to fullt test it, and ensure there are no regressions. The series touches too many things inside virt-v2v. [*] partially my fault for not having reviewed it, however that's what happens when certain LPs (hello IMS!) ask your team to do the work of 5 people at once Even assuming it was easy and doable, there is a detail that is being forgotten: (In reply to Fabien Dupont from comment #0) > For example: > $ virt-v2v -i vmx -it ssh -ip /tmp/passwd \ > 'ssh://root@esxi/vmfs/volumes/datastore1/Windows/Windows.vmx' -o null Both the copying of the vmx file from the ESXi server and the check for the existance (always on the ESXi datastore) are done spawning ssh(1) manually, the password file specified with -ip does not apply to them, and thus the SSH password is still asked (twice). A possible solution is to use libssh to do these connections, and I have a possible draft for it. Again, see [*] above for the "why it is not done already. --- Bottom like: let's test this upstream _properly_, and have it picked in future rebases of virt-v2v. (Explicitly said: NACK from me.) I'm fine with waiting for rebase. It would be a great enhancement, but we have a working process in IMS. No need to rush. PS: I plead guilty on IMS behalf. Note: after the rebase of virt-v2v to 1.42.0: - Xen should be fully covered by -ip - vmx via ssh transport still asks for the password twice, for the reasons mentioned in the second half of comment 3 I'm ACKing this because I think it should already have been fixed when we rebased to virt-v2v 1.42. mxie: Could you QA ack this please? Sorry for misunderstanding the bug,retest the bug with builds: virt-v2v-1.42.0-12.module+el8.5.0+10976+d40a93e9.x86_64 Steps: Not set ssh-agent Scenario 1:Convert guest from xen host: # virt-v2v -ic xen+ssh://root.224.33 xen-hvm-rhel7.9-x86_64 -of raw -ip /home/rhvpasswd virt-v2v: error: ssh-agent authentication has not been set up ($SSH_AUTH_SOCK is not set). This is required by qemu to do passwordless ssh access. See the virt-v2v(1) man page for more information. If reporting bugs, run virt-v2v with debugging enabled and include the complete output: virt-v2v -v -x [...] Result 1: virt-v2v still cannot use password to convert guests from xen host Scenario 2: convert a guest from ESXI7.0 server # virt-v2v -i vmx -it ssh ssh://root.199.217/vmfs/volumes/esx7.0-matrix/esx7.0-win2019-x86_64/esx7.0-win2019-x86_64.vmx -o rhv-upload -oc https://hp-dl360eg8-03.lab.eng.pek2.redhat.com/ovirt-engine/api -os iscsi_data -op /home/rhvpasswd -oo rhv-cafile=/home/ca.pem -of raw -b ovirtmgmt -oa preallocated -oo rhv-cluster=ISCSI -oo rhv-verifypeer=false -ip /home/rhvpasswd [ 0.5] Opening the source -i vmx ssh://root.199.217/vmfs/volumes/esx7.0-matrix/esx7.0-win2019-x86_64/esx7.0-win2019-x86_64.vmx Password: Password: [ 10.7] Creating an overlay to protect the source from being modified nbdkit: ssh[1]: error: all possible authentication methods failed qemu-img: /var/tmp/v2vovl5d4459.qcow2: Requested export not available Could not open backing image. virt-v2v: error: qemu-img command failed, see earlier errors If reporting bugs, run virt-v2v with debugging enabled and include the complete output: virt-v2v -v -x [...] Result 2:virt-v2v cannot use password to convert guests from ESXI7.0 Scenario 3: convert guest from ESXI6.7 server # virt-v2v -i vmx -it ssh ssh://root.75.219/vmfs/volumes/esx6.7-matrix/esx6.7-win10-x86_64-efi/esx6.7-win10-x86_64-efi.vmx -ip /home/esxpw [ 0.0] Opening the source -i vmx ssh://root.75.219/vmfs/volumes/esx6.7-matrix/esx6.7-win10-x86_64-efi/esx6.7-win10-x86_64-efi.vmx Password: Password: [ 17.0] Creating an overlay to protect the source from being modified [ 17.2] Opening the overlay [ 25.9] Inspecting the overlay [...] [ 759.7] Finishing off Result 3:virt-v2v can use password to convert guests from ESXI6.7 Also test other ESXI server,result as below: Result: XEN FAIL ESXI7.0 FAIL ESXI6.7 PASS ESXI6.5 PASS ESXI6.0 FAIL ESXI5.5 FAIL Hi,Rjones Pls help to check the result. Thanks! This has obviously not been fixed/implemented properly. I'm putting it back on the backlog and moving to RHEL 9 (as we want to do as little as possible for RHEL 8 and certainly not add features). Clearing ITR, DTM, ITM - more completeness. After evaluating this issue, there are no plans to address it further or fix it in an upcoming release. Therefore, it is being closed. If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened. This bug was closed in error by a process that we do not control. Reopening. Given that this BZ has been moved to RHEL9, and we've recently taken multiple stabs at this in bug 1854275, I'm closing this one as a duplicate of bug 1854275. Summary of the status (all documented in the virt-v2v manual): - xen+ssh: if the server enables PasswordAuthentication, then "-ip" works. - vmx+ssh: even if the server enables PasswordAuthentication and "-ip" is passed on the command line, the vmx input module with ssh transport still asks twice for the password, because the "scp" and "ssh" invocations we have in there cannot be convinced to take the password otherwise. This could only be mitigated by an internal SFTP client, which is too much work (= too little capacity) for the requested feature. Use ssh-agent please. The manual is also clear about this (now). *** This bug has been marked as a duplicate of bug 1854275 *** |
Description of problem: It would be great to be able to use password based authentication for SSH transport with virt-v2v, and not just SSH private key. For example: $ virt-v2v -i vmx -it ssh -ip /tmp/passwd \ 'ssh://root@esxi/vmfs/volumes/datastore1/Windows/Windows.vmx' -o null