Bug 1854275

Created attachment 1700099 [details]
xen-password-file.log

Below is the reply from rjones in the mail
-------------------------------------------------------------------
Pino noticed this before and it's caused by the upstream change:

https://github.com/libguestfs/virt-v2v/commit/22171a97812f0e7556a1adeca4c2e108c6f4082d

which didn't catch all the places where ssh is used (and therefore the
feature is incomplete).  This is why it's asking for a password still.

The actual problem is:

>  LANG=C 'nbdkit' '--exit-with-parent' '--foreground' '--newstyle' '--pidfile' '/tmp/v2vnbdkit.uSrakJ/nbdkit1.pid' '--unix' '/tmp/v2vnbdkit.uSrakJ/nbdkit1.sock' '-D' 'nbdkit.backend.datapath=0' '--exportname' '/' '--readonly' '--selinux-label' 'system_u:object_r:svirt_socket_t:s0' '--verbose' '--filter' 'cacheextents' '--filter' 'readahead' '--filter' 'retry' 'ssh' 'host=10.73.75.219' 'user=root' 'path=/vmfs/volumes/esx6.7-matrix/esx6.7-win10-x86_64-efi/esx6.7-win10-x86_64-efi-flat.vmdk' 'password=+/home/esxpw'
[...]
> nbdkit: ssh[1]: error: all possible authentication methods failed

I'm able to reproduce this locally quite easily:

  $ ssh root.75.219
  # accept the ssh key, but don't log in

  $ echo *** > /tmp/passwd
  $ nbdkit -fvr ssh host=10.73.75.219 user=root path=/vmfs/volumes/esx6.7-matrix/esx6.7-win10-x86_64-efi/esx6.7-win10-x86_64-efi-flat.vmdk password=+/tmp/passwd

and from another window do something like:

  $ qemu-img info nbd:localhost:10809
  qemu-img: Could not open 'nbd:localhost:10809': Requested export not available

You will see that nbdkit prints the same error as above.

I couldn't actually tell from the debug messages what the problem is,
so I added the extra nbdkit parameter -D ssh.log=2 which enables very
verbose SSH logging.  The reason turns out to be that this server does
not offer password authentication (only "keyboard-interactive" which
is different, and which we cannot use from a server, and "publickey"
which we don't want to use).

On the VMware server in /etc/ssh/sshd_config is:

  # only use PAM challenge-response (keyboard-interactive)
  PasswordAuthentication no

If you change that to "yes" it should work.

------------------------------------------------------------------------

Hi Richard,

   You are right, if change 'yes' for PasswordAuthentication on VMware host, then v2v can convert a guest from VMX via ssh with -ip option, but still need to input password manually during conversion. And I have a question for scenario2, is -ip a required option for SSH password authentication? If yes, maybe need to improve the error info for sceanrio2.

1.Change 'yes' for PasswordAuthentication on VMware host and restart management agents 
#cat /etc/ssh/sshd_config |grep PasswordAuthentication
PasswordAuthentication yes
#/etc/init.d/hostd restart
#/etc/init.d/vpxa restart

Scenario1: don't set ssh-agent for VMware host and use v2v to convert a guest from VMX via ssh with -ip option
# 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 -on vmx+ssh-password-file
[   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: 
[   7.4] Creating an overlay to protect the source from being modified
[   7.7] Opening the overlay
[  13.3] Inspecting the overlay
[  20.7] Checking for sufficient free disk space in the guest
[  20.7] Estimating space required on target for each disk
[  20.7] Converting Windows 10 Enterprise to run on KVM
virt-v2v: warning: /usr/share/virt-tools/pnp_wait.exe is missing.  
Firstboot scripts may conflict with PnP.
virt-v2v: warning: there is no QXL driver for this version of Windows (10.0 
x86_64).  virt-v2v looks for this driver in 
/usr/share/virtio-win/virtio-win.iso

The guest will be configured to use a basic VGA display driver.
virt-v2v: This guest has virtio drivers installed.
[  35.3] Mapping filesystem data to avoid copying unused and blank areas
virt-v2v: warning: fstrim on guest filesystem /dev/sda2 failed.  Usually 
you can ignore this message.  To find out more read "Trimming" in 
virt-v2v(1).

Original message: fstrim: fstrim: /sysroot/: the discard operation is not 
supported
[  36.8] Closing the overlay
[  36.9] Assigning disks to buses
[  36.9] Checking if the guest needs BIOS or UEFI to boot
virt-v2v: This guest requires UEFI on the target to boot.
[  36.9] Initializing the target -o libvirt -os default
[  36.9] Copying disk 1/1 to /var/lib/libvirt/images/vmx+ssh-password-file-sda (raw)
    (100.00/100%)
[ 548.4] Creating output metadata
virt-v2v: warning: could not define libvirt domain: unsupported 
configuration: IDE controllers are unsupported for this QEMU binary or 
machine type.
The libvirt XML is still available in ‘/tmp/v2vlibvirt7b9e6d.xml’.  Try 
running ‘virsh -c qemu:///system define /tmp/v2vlibvirt7b9e6d.xml’ 
yourself instead.
[ 548.4] Finishing off


Scenario2: don't set ssh-agent for VMware host and use v2v to convert a guest from VMX via ssh without -ip option
# 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 -on vmx+ssh-password-file
[   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: 
[   6.9] Creating an overlay to protect the source from being modified
nbdkit: ssh[1]: error: all possible authentication methods failed
qemu-img: /var/tmp/v2vovl4bbd75.qcow2: Requested export not available
Could not open backing image to determine size.
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 [...]

This feature as implemented was a bit broken for vmx+ssh.  There are
a couple of separate issues:

(1) Need to somehow supply the password to the discrete ssh commands
that we run.  (This is the hard one to solve)

(2) Document that sshd on the VMware server needs to allow password
authentication, which may require changing /etc/ssh/sshd_config on the
server side.  (The easy one)

The easy docs fix is:
https://github.com/libguestfs/virt-v2v/commit/784be60842d088596d7af938f90c689083677dca

This does NOT solve the bigger issue (1) in comment 3.

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.

No this bug is NOT invalid, the previous comment is nonsense.

I'm not sure how many issues we have here.

- One would be nbdkit using ssh_userauth_password() in
  "plugins/ssh/ssh.c". This is good for password authentication, but not
  for keyboard-interactive. If this is the problem, then this BZ should
  belong to nbdkit.

  (keyboard-interactive is explained e.g. here:
  <https://superuser.com/questions/894608/ssh-o-preferredauthentications-whats-the-difference-between-password-and-k/894625>:

> "keyboard-interactive" user authentication is intended primarily to
> accomodate PAM authentication on the server side. It provides for a
> multiple challenge- response dialog with the user in which the server
> sends a text query to the user, the user types in a response, and this
> process can repeat any number of  times. So for example, you might
> configure PAM for SSH with a module which performs authentication
> using an RSA security token, or a one-time password scheme.  People
> become confused by this because by default, "keyboard-interactive"
> authentication usually just implements password authentication in a
> single challenge- response cycle, which just prompts for a password,
> thus looking exactly the same as "password" authentication. If you're
> not deliberately using both for  different purposes, you may want to
> disable one or the other to avoid end-user confusion.

  For this, nbdkit could perhaps use ssh_userauth_kbdint_*(), but how
  we'd drive that from a simple regular "password file" (considering
  multiple prompts from the server, for example) is not clear at all.

  I think this is too much complexity for too little gain;
  PasswordAuthentication (which is already documented) and ssh-agent
  both work, those should suffice.

- The other problem could be:

  (In reply to Richard W.M. Jones from comment #3)

> (1) Need to somehow supply the password to the discrete ssh commands
> that we run.  (This is the hard one to solve)

  The only "naked" ssh invocation I see in virt-v2v is in function
  "remote_file_exists", file "input/parse_domain_from_vmx.ml"; what are
  the others?

For virt-v2v, I think we should give up attempting to support
interactive passwords.  The -ip option is easy enough to use.
When fixing bug 1960087 that was the approach that I took.

(In reply to Laszlo Ersek from comment #11)
> I'm not sure how many issues we have here.
> 
> - One would be nbdkit using ssh_userauth_password() in
>   "plugins/ssh/ssh.c". This is good for password authentication, but not
>   for keyboard-interactive. If this is the problem, then this BZ should
>   belong to nbdkit.
> 
>   (keyboard-interactive is explained e.g. here:

nbdkit documents that it doesn't support keyboard-interactive
https://libguestfs.org/nbdkit-ssh-plugin.1.html#Supported-authentication-methods
The reason is because it's a server and it has possibly forked
by the time we begin the connection to the remote server.

> <https://superuser.com/questions/894608/ssh-o-preferredauthentications-whats-
> the-difference-between-password-and-k/894625>:
> 
> > "keyboard-interactive" user authentication is intended primarily to
> > accomodate PAM authentication on the server side. It provides for a
> > multiple challenge- response dialog with the user in which the server
> > sends a text query to the user, the user types in a response, and this
> > process can repeat any number of  times. So for example, you might
> > configure PAM for SSH with a module which performs authentication
> > using an RSA security token, or a one-time password scheme.  People
> > become confused by this because by default, "keyboard-interactive"
> > authentication usually just implements password authentication in a
> > single challenge- response cycle, which just prompts for a password,
> > thus looking exactly the same as "password" authentication. If you're
> > not deliberately using both for  different purposes, you may want to
> > disable one or the other to avoid end-user confusion.
> 
>   For this, nbdkit could perhaps use ssh_userauth_kbdint_*(), but how
>   we'd drive that from a simple regular "password file" (considering
>   multiple prompts from the server, for example) is not clear at all.
> 
>   I think this is too much complexity for too little gain;
>   PasswordAuthentication (which is already documented) and ssh-agent
>   both work, those should suffice.

I agree.

> - The other problem could be:
> 
>   (In reply to Richard W.M. Jones from comment #3)
> 
> > (1) Need to somehow supply the password to the discrete ssh commands
> > that we run.  (This is the hard one to solve)
> 
>   The only "naked" ssh invocation I see in virt-v2v is in function
>   "remote_file_exists", file "input/parse_domain_from_vmx.ml"; what are
>   the others?

In the same file we invoke scp in scp_from_remote_to_temporary
which is a variation of the same problem.

(In reply to Richard W.M. Jones from comment #12)
> >   (In reply to Richard W.M. Jones from comment #3)
> > 
> > > (1) Need to somehow supply the password to the discrete ssh commands
> > > that we run.  (This is the hard one to solve)
> > 
> >   The only "naked" ssh invocation I see in virt-v2v is in function
> >   "remote_file_exists", file "input/parse_domain_from_vmx.ml"; what are
> >   the others?
> 
> In the same file we invoke scp in scp_from_remote_to_temporary
> which is a variation of the same problem.

So I've done some reading on the web, and it's quite obvious that scp and ssh intentionally do not support taking a plaintext password from a regular file (or even from a file descriptor). StackOverflow and similar sites are full of this question ("how do I fool ssh into taking a pre-set plaintext password"). Some people recommend "expect", some recommend "sshpass" <https://linux.die.net/man/1/sshpass>. The latter writes:

"""
ssh uses direct TTY access to make sure that the password is indeed issued by an interactive keyboard user. Sshpass runs ssh in a dedicated tty, fooling it into thinking it is getting the password from an interactive user. [...] First and foremost, users of sshpass should realize that ssh's insistance on only getting the password interactively is not without reason.
"""

I don't think we'll ever cleanly automate this using command line tools, as OpenSSH itself seems dead-set against it. So what remains are the traditional (secure) passwordless logins, such as pubkey, agent, and controlmaster. PubKey we don't want to use (comment 2), controlmaster is much more obscure than agent, and agent already works fine ("additional info" in comment 0).

(Side comment: our "error_if_no_ssh_agent" function [lib/utils.mli] is no longer used; its only (or last) use, apparently for Xen-over-SSH, was eliminated in commit 255722cbf39a ("v2v: Modular virt-v2v", 2021-09-07).)

The only solution I see for completing commit 22171a97812f is to reimplement "remote_file_exists" and "scp_from_remote_to_temporary" in C, using libssh (an sftp session). I think we can use nbdkit's "plugins/ssh/ssh.c" as example.

For "remote_file_exists", we can replace "test -f" with sftp_lstat().

For "scp_from_remote_to_temporary", we can write a simple SFTP download loop, using (e.g.) just 32KB for request size. The function is only used for retrieving "source.vmx", and a VMX file is not big (it's just a config file).

Is this feature (-ip ...) worth all the above work? (The BZ is marked as Prio=high Sev=high, so maybe?) I think it's doable, "just" lots of work.

As an alternative, we could just document that -ip ... does not fully work for vmx+ssh, and the only way to get rid of the password prompts is to use ssh-agent.

(In reply to Laszlo Ersek from comment #13)

> For "remote_file_exists", we can replace "test -f" with sftp_lstat().

Sigh, I specifically wanted to *avoid* lstat here: just use sftp_stat(), as "test -f" does dereference symlinks.

> Is this feature (-ip ...) worth all the above work?

vmx+ssh is pretty niche, so I would say no it's not worth going
through hoops to make this work.  We would however need to document
what works and what doesn't correctly in the manual pages.

> (The BZ is marked as Prio=high Sev=high, so maybe?) I think it's doable,
> "just" lots of work.

I never pay any attention to those fields and looking through
BZ history I'm not sure who set them, but don't worry about
bug priority.

[v2v PATCH] docs: highlight that "-ip" with vmx+ssh still requires user interaction
Message-Id: <20220217145638.9324-1-lersek>
https://listman.redhat.com/archives/libguestfs/2022-February/msg00264.html

(In reply to Laszlo Ersek from comment #16)
> [v2v PATCH] docs: highlight that "-ip" with vmx+ssh still requires user interaction
> Message-Id: <20220217145638.9324-1-lersek>
> https://listman.redhat.com/archives/libguestfs/2022-February/msg00264.html

Upstream commit 3172a509bb43.

I'm updating the BZ metadata to show that we haven't actually implemented the feature, but documented the limitation.

Verified with the version: virt-v2v-2.0.0-2.el9.x86_64.

# man virt-v2v-input-vmware
........
 VMX: SSH authentication

       You can use SSH password authentication, by supplying the name of a file containing the password to the -ip option (note this option
       does not take the password directly).  You may need to adjust /etc/ssh/sshd_config on the VMware server to set "PasswordAuthentication
       yes".

       If you are not using password authentication, an alternative is to use ssh-agent, and add your ssh public key to
       /etc/ssh/keys-root/authorized_keys (on the ESXi hypervisor).  After doing this, you should check that passwordless access works from
       the virt-v2v server to the ESXi hypervisor.  For example:

        $ ssh root.com
        [ logs straight into the shell, no password is requested ]

       Note that support for non-interactive authentication via the -ip option is incomplete.  Some operations remain that still require the
       user to enter the password manually.  Therefore ssh-agent is recommended over the -ip option.  See https://bugzilla.redhat.com/1854275.
........

Moving to Verified:Tested.

For the issues mentioned in Description, the xen+ssh has NOT been fixed.

Checked with virt-v2v-2.0.2-1.el9.x86_64.

# man virt-v2v-input-xen
......
INPUT FROM XEN
   SSH authentication
       You can use SSH password authentication, by supplying the name of a file containing the password to the -ip option (note this option
       does not take the password directly).

       If you are not using password authentication, an alternative is to use ssh-agent, and add your ssh public key to
       /root/.ssh/authorized_keys (on the Xen host).  After doing this, you should check that passwordless access works from the virt-v2v
       server to the Xen host.  For example:

        $ ssh root.com
        [ logs straight into the shell, no password is requested ]

......

rjones and Laszlo, could you take a look at it?

I don't think the documentation is wrong, although perhaps it's a bit
confusing.  Password authentication does actually work if you use the
-ip option, it's just that the -ip option doesn't cover every case -
you'll still get interactive prompts for ssh and scp commands that we
run (at least until we fix that by using sftp in future).

The recommendation is to use ssh-agent though which solves the
problem completely.

Is the problem that commit 3172a509bb43 (comment 17) only modified "docs/virt-v2v-input-vmware.pod", and did not duplicate the same paragraph to "docs/virt-v2v-input-xen.pod", after "[ logs straight into the shell, no password is requested ]"?

If that's desired, I guess I could submit an upstream patch like that (not sure how helpful it is though).

(In reply to Laszlo Ersek from comment #23)
> Is the problem that commit 3172a509bb43 (comment 17) only modified
> "docs/virt-v2v-input-vmware.pod", and did not duplicate the same paragraph
> to "docs/virt-v2v-input-xen.pod", after "[ logs straight into the shell, no
> password is requested ]"?
> 
> If that's desired, I guess I could submit an upstream patch like that (not
> sure how helpful it is though).

I suggest we add the same paragraph to "docs/virt-v2v-input-xen.pod" as in the "docs/virt-v2v-input-vmware.pod".

OK, please flip this back to ASSIGNED then. Thanks.

(... I would have appreciated the same observation in comment 18 though :/)

I think SSH authentication part of virt-v2v-input-xen man is correct because -ip option works in xen+ssh conversion 

# virt-v2v -ic xen+ssh://root.224.33 xen-hvm-rhel7.9-x86_64 -ip /home/esxpw  -o null
[   0.0] Setting up the source: -i libvirt -ic xen+ssh://root.224.33 xen-hvm-rhel7.9-x86_64
root.224.33's password: 
[   4.7] Opening the source
[   9.1] Inspecting the source
[  20.4] Checking for sufficient free disk space in the guest
[  20.4] Converting Red Hat Enterprise Linux Server 7.9 (Maipo) to run on KVM
virt-v2v: This guest has virtio drivers installed.
[ 157.4] Mapping filesystem data to avoid copying unused and blank areas
[ 158.4] Closing the overlay
[ 158.5] Assigning disks to buses
[ 158.5] Checking if the guest needs BIOS or UEFI to boot
[ 158.5] Setting up the destination: -o null
[ 159.8] Copying disk 1/1
█ 100% [****************************************]
[ 258.5] Creating output metadata
[ 258.5] Finishing off

Tried the scenario on setting  "PasswordAuthentication no" in /etc/ssh/sshd_config on the xen server.

The -ip option can't work. Better to add in man page of xen+ssh.


]# virt-v2v -ic xen+ssh://root.224.33 xen-hvm-rhel7.9-x86_64 -ip /xenpw -o null
[   1.3] Setting up the source: -i libvirt -ic xen+ssh://root.224.33 xen-hvm-rhel7.9-x86_64
virt-v2v: error: exception: libvirt: VIR_ERR_SYSTEM_ERROR: VIR_FROM_RPC: 
Cannot recv data: root.224.33: Permission denied 
(publickey,gssapi-with-mic).: Connection reset by peer

If reporting bugs, run virt-v2v with debugging enabled and include the 
complete output:

  virt-v2v -v -x [...]

Flip back to ASSIGNED. Thanks.

Hi Vera,

actually, after reviewing the comments starting with comment 22, I have
a different opinion -- I agree we should extend the Xen-related docs
indeed; however, I think what's needed is not a comment about the "-ip"
option not working. Instead, what we should add is a comment about the
"PasswordAuthentication" sshd config option.

Compare the following two paragraphs:

https://libguestfs.org/virt-v2v-input-vmware.1.html#vmx:-ssh-authentication

> VMX: SSH authentication
>
> You can use SSH password authentication, by supplying the name of a
> file containing the password to the -ip option (note this option does
> not take the password directly). You may need to adjust
> /etc/ssh/sshd_config on the VMware server to set
> PasswordAuthentication yes.
>
> If you are not using password authentication, an alternative is to use
> ssh-agent, and add your ssh public key to
> /etc/ssh/keys-root/authorized_keys (on the ESXi hypervisor). After
> doing this, you should check that passwordless access works from the
> virt-v2v server to the ESXi hypervisor. For example:
>
>  $ ssh root.com
>  [ logs straight into the shell, no password is requested ]
>
> Note that support for non-interactive authentication via the -ip
> option is incomplete. Some operations remain that still require the
> user to enter the password manually. Therefore ssh-agent is
> recommended over the -ip option. See
> https://bugzilla.redhat.com/1854275.

versus

https://libguestfs.org/virt-v2v-input-xen.1.html#ssh-authentication

> SSH authentication
>
> You can use SSH password authentication, by supplying the name of a
> file containing the password to the -ip option (note this option does
> not take the password directly).
>
> If you are not using password authentication, an alternative is to use
> ssh-agent, and add your ssh public key to /root/.ssh/authorized_keys
> (on the Xen host). After doing this, you should check that
> passwordless access works from the virt-v2v server to the Xen host.
> For example:
>
>  $ ssh root.com
>  [ logs straight into the shell, no password is requested ]
>
> With some modern ssh implementations, legacy crypto policies required
> to interoperate with RHEL 5 sshd are disabled. To enable them you may
> need to run this command on the conversion server (ie. ssh client),
> but read update-crypto-policies(8) first:
>
>  # update-crypto-policies --set LEGACY

The differences are:

(1) vmx+ssh refers to "PasswordAuthentication", xen+ssh does not.

(2) vmx+ssh refers to the incomplete nature of the "-ip" option, xen+ssh
does not.

(3) xen+ssh refers to legacy crypto, vmx+ssh does not.

Now, from these differences, (2) and (3) are *justified*. Here's why:

- Regarding (2), the vmx+ssh transport indeed makes such ssh / scp calls
  that ignore the "-ip" option. See
  <https://bugzilla.redhat.com/show_bug.cgi?id=1854275#c12>. However,
  the xen+ssh transport does *not* contain such invocations. See also
  Ming's test in
  <https://bugzilla.redhat.com/show_bug.cgi?id=1854275#c26>. Therefore,
  documenting any "-ip" shortcomings for xen+ssh would be wrong.

- Regarding (3), vmx+ssh is used against ESXi servers, and those do not
  suffer from outdated crypto (unlike some Xen servers might).
  Therefore, documenting legacy crypto for vmx+ssh would be wrong.

The real problem is (1): we do not document the "PasswordAuthentication"
requirement (on the server side) for xen+ssh. This is consistent with
your test in <https://bugzilla.redhat.com/show_bug.cgi?id=1854275#c27>.

Therefore, rather than mirroring commit 3172a509bb43 to the Xen-related
docs, what we should add is the following sentence:

  You may need to adjust /etc/ssh/sshd_config on the Xen server to set
  PasswordAuthentication yes.

Do you agree? Thank you.

> (1) vmx+ssh refers to "PasswordAuthentication", xen+ssh does not.
> 
> (2) vmx+ssh refers to the incomplete nature of the "-ip" option, xen+ssh
> does not.
> 
> (3) xen+ssh refers to legacy crypto, vmx+ssh does not.
> 
> Now, from these differences, (2) and (3) are *justified*. Here's why:
> 
> - Regarding (2), the vmx+ssh transport indeed makes such ssh / scp calls
>   that ignore the "-ip" option. See
>   <https://bugzilla.redhat.com/show_bug.cgi?id=1854275#c12>. However,
>   the xen+ssh transport does *not* contain such invocations. See also
>   Ming's test in
>   <https://bugzilla.redhat.com/show_bug.cgi?id=1854275#c26>. Therefore,
>   documenting any "-ip" shortcomings for xen+ssh would be wrong.

-ip filename
    Supply a file containing a password to be used when connecting to the target hypervisor.  If this is omitted then the input hypervisor may ask for the password interactively.

From my understanding, that means users will not be prompted typing a password with '-ip' option.
If that's right, then the prompt is a problem. or maybe my understanding is wrong?

e.g.
# virt-v2v -ic xen+ssh://root.224.33 xen-hvm-rhel7.9-x86_64 -ip /home/esxpw  -o null
[   0.0] Setting up the source: -i libvirt -ic xen+ssh://root.224.33 xen-hvm-rhel7.9-x86_64
root.224.33's password: 

If this behavior is expected in some scenarios, how about documenting that in the '-ip' option?

I don't know how to make *all* the documenation complete and consistent.

- For "-ip" to work with ssh (xen or vmx), you need PasswordAuthentication on the server.
- But there are locations in virt-v2v (involving vmx) where "-ip" is not even considered (because we can't, without adding a relatively full-blown SFTP client to virt-v2v).

My suggestion from comment 33 completes the documentation for the xen+ssh case. Modifying the *general* description of the "-ip" option is not a good idea in my opinion. "-ip" is used with other transports as well; for example <https://libguestfs.org/virt-v2v-input-vmware.1.html>:

 virt-v2v
    -ic 'vpx://root.com/Datacenter/esxi?no_verify=1'
    -ip passwordfile
    "GUEST NAME" [-o* options]

[v2v PATCH] input-xen: sync PasswordAuthentication hint from input-vmware manual
Message-Id: <20220409065512.7515-1-lersek>
https://listman.redhat.com/archives/libguestfs/2022-April/028628.html

(In reply to Laszlo Ersek from comment #36)
> [v2v PATCH] input-xen: sync PasswordAuthentication hint from input-vmware manual
> Message-Id: <20220409065512.7515-1-lersek>
> https://listman.redhat.com/archives/libguestfs/2022-April/028628.html

Upstream commit 46298c651471.

*** Bug 1790962 has been marked as a duplicate of this bug. ***

Verified with the version: virt-v2v-2.0.3-1.el9.x86_64

# man virt-v2v-input-xen

INPUT FROM XEN
...
   SSH authentication
       You can use SSH password authentication, by supplying the name of a file containing the password to the -ip option (note this option
       does not take the password directly).  You may need to adjust /etc/ssh/sshd_config on the Xen server to set "PasswordAuthentication
       yes".


# man virt-v2v-input-vmware
...
       VMX: SSH authentication

       You can use SSH password authentication, by supplying the name of a file containing the password to the -ip option (note this option
       does not take the password directly).  You may need to adjust /etc/ssh/sshd_config on the VMware server to set "PasswordAuthentication
       yes".


Moving to Verified.

(In reply to Laszlo Ersek from comment #33)

> (2) vmx+ssh refers to the incomplete nature of the "-ip" option, xen+ssh
> does not.

> - Regarding (2), the vmx+ssh transport indeed makes such ssh / scp calls
>   that ignore the "-ip" option. See
>   <https://bugzilla.redhat.com/show_bug.cgi?id=1854275#c12>. However,
>   the xen+ssh transport does *not* contain such invocations. See also
>   Ming's test in
>   <https://bugzilla.redhat.com/show_bug.cgi?id=1854275#c26>. Therefore,
>   documenting any "-ip" shortcomings for xen+ssh would be wrong.

Unfortunately, I was wrong about this. While virt-v2v itself doesn't invoke sftp / ssh / scp for xen+ssh itself, it does call Libvirt.Connect.connect_auth, which (quite indirectly) does end up launching an "ssh" binary, from the libvirt (client side) library. Which requires a password just the same, and ignores "-ip" just the same.

I'm fixing this as a part of bug 2062360, by porting commit 3172a509bb43 to virt-v2v-input-xen.

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 (Low: virt-v2v security, bug fix, and enhancement update), 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://access.redhat.com/errata/RHSA-2022:7968

This was reverted in the following commit:
https://github.com/libguestfs/virt-v2v/commit/67fcf66904c7f1f6da858eba35e95dad670427c0
because we now think that the -ip option is fixed and should work everywhere for ssh connections.