MITM message refers to non-existent file

Bug #1883462 reported by Peter Matulis
14
This bug affects 3 people
Affects Status Importance Assigned to Milestone
uvtool
Expired
Undecided
Unassigned

Bug Description

[Triage Notes]

This has become a "pile-on bug report" with users experiencing common symptoms that are likely to have separate root causes. If you're experiencing symptoms similar to those reported here and you wish to comment, please file a *separate* bug and provide full steps to reproduce your problem.

Otherwise we get different people with different root causes, confusion, and an impossible to resolve bug, which helps nobody.

[Original Report]

The MITM message that appears when attempting to contact an instance refers to a known hosts file that does not exist.

$ uvt-kvm ssh test

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
SHA256:+IFxGk064SOo0prxRBJ9njh0dH5hjrqnhOQz5At+g8M.
Please contact your system administrator.
Add correct host key in /tmp/uvt-kvm.known_hoststmpod9e8ys2 to get rid of this message.
Offending ED25519 key in /tmp/uvt-kvm.known_hoststmpod9e8ys2:4
  remove with:
  ssh-keygen -f "/tmp/uvt-kvm.known_hoststmpod9e8ys2" -R "192.168.122.2"
ECDSA host key for 192.168.122.2 has changed and you have requested strict checking.
Host key verification failed.

$ ssh-keygen -f "/tmp/uvt-kvm.known_hoststmpod9e8ys2" -R "192.168.122.2"
do_known_hosts: hostkeys_foreach failed: No such file or directory

Revision history for this message
Robie Basak (racb) wrote :

Thank you for the report!

Could you explain your use case please, and provide steps to reproduce?

There's quite a bit I could explain about the background on design and behaviour on this area, but it would be very verbose and so it would help if I could understand exactly how you're hitting this and what problem you're trying to solve first. Thanks!

Changed in uvtool:
status: New → Incomplete
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for uvtool because there has been no activity for 60 days.]

Changed in uvtool:
status: Incomplete → Expired
Revision history for this message
Raphaël (raph8) wrote :

the first vm I've created was ok. After that every vm created with the same name this problem appear
there is no /tmp/uvt-kvm.known_* file.

Revision history for this message
Robie Basak (racb) wrote :

@Raphaël

If you think that what you're seeing is a bug in uvtool, then please could you file a separate bug with full details - steps to reproduce, expected behaviour, and actual behaviour? Since there's no guarantee that you have the same issue here, otherwise it'll confuse things if multiple people are using this bug to track different root causes with the same symptom.

Revision history for this message
Vicaya Ubuntu (vicaya) wrote :

Ran into the same problem after use virt-clone and virt-sysprep (which resets the host keys) to clone a VM that was created by uvt-kvm, which embeds <uvt:ssh_known_hosts...> in the metadata section of the libvirt xml. The workaround is to use virsh edit to delete the offending metadata and you're good to go.

IMO, the uvt-kvm hack (embedding host keys in libvirt xml) is a bad design that causes more troubles than its worth.

Changed in uvtool:
status: Expired → New
Revision history for this message
Robie Basak (racb) wrote :

It's interesting to hear that you're using uvtool to generate VMs to be cloned, including the libvirt XML. That isn't a use case I originally intended for uvtool to support.

> IMO, the uvt-kvm hack (embedding host keys in libvirt xml) is a bad design that causes more troubles than its worth.

IMHO, it's not a hack. libvirt supports custom XML, and we use it. If you replace the host keys, then you can expect "uvt-kvm ssh" not to be able to work, since it needs to know the host keys for seamless operation in the primary use case. The point of "uvt-kvm ssh" is to do host key verification correctly and seamlessly. This is the entire point of it; you can just use plain ssh if you don't want that, possibly with "uvt-kvm ip" if you need to conveniently look up the IP. The seamless operation requires the host machine to know the guest's ssh host public key.

Therefore I would say that your workaround (or an update of the libvirt XML to the new host key) is a requirement if you wish to clone the libvirt definition _and_ expect "uvt-kvm ssh" to work.

However, I'm not sure that this root cause of your issue is the same as the one reported by Peter, so I'm setting this bug back to Incomplete since we're still awaiting reproduction steps for that.

Changed in uvtool:
status: New → Incomplete
description: updated
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for uvtool because there has been no activity for 60 days.]

Changed in uvtool:
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.