0

I have a server running Ovirt Node that I'm trying to manage remotely using libvirt. I have an SSH keypair installed and can ssh user@server -i ssh-privkey successfully. When I try to connect to qemu+ssh//user@host/system?keyfile=ssh-privkey, I get this error:

authentication failed: Failed to start SASL negotiation: -4 (SASL(-4): no mechanism available: No worthy mechs found)

That led me down the path of getting TLS keys and certificates installed on the client and the server mostly according to these instructions (the configuration is slightly different because I have only one host and am using Terraform to manage the certificates*). However, I still get the same error. When I look at the output of libvirt --listen --verbose on the server when a connection failed, the only useful output is this:

error : virNetSocketReadWire:1792 : End of file while reading data: Input/output error

I have checked every firewall between the client and the server and they should all be wide open. What else could be the cause of this error?

* The goal is ultimately to use Terraform to provision libvirt resources, however I get the same errors trying to connect with virsh and virt-manager.

UPDATE: It's easier to connect just via SSH; this question exists because I couldn't figure out how to turn off SASL. It turns out SASL is enabled for SSH connections due to vdsm setting auth_unix_rw="sasl" in /etc/libvirt/libvirtd.conf. Removing that config means I can just use my SSH private key as I intended. The TLS configuration was a wild goose chase that was further hindered by vdsm changing the configured location of all the PKI files.

meustrus
  • 6,637
  • 5
  • 42
  • 53

1 Answers1

1

You're likely missing a RPM package on your client host. First on the virtualization host check /etc/sasl2/libvirt.conf and see what 'mech_list' setting is uncommented.

Back on your client you'll need to install a 'cyrus-sasl-XXXX' RPM that provides the same mechanism that the server is set to use. For a modern libvirt install it will probably be using 'cyrus-sasl-scram' for plain username/password auth, but for older installs, it might still be using 'cyrus-sasl-md5'

DanielB
  • 2,461
  • 1
  • 10
  • 13
  • My server shows `mech_list: scram-sha-256`. My client is Debian-based and doesn't have a `cyrus-sasl-scram` package. Do you know what is needed in Debian, or do I just need to use a Red Hat based OS? Obviously not ideal but it wouldn't be as inconvenient for me since the client is already in a VM to be Linux at all. – meustrus Jun 22 '22 at 21:44
  • 1
    For inexplicable reasons, Debian put the SCRAM module in the the GSSAPI package libsasl2-modules-gssapi-mit – DanielB Jun 23 '22 at 13:36
  • That worked, thank you! At least, it works in virt-manager, when I put in a username/password. Is there any way to either not require a SASL username/password, embed it in the connection URI, or embed it in the environment similar to `ssh-agent`? Terraform is failing because it has no mechanism to supply the username/password. – meustrus Jun 24 '22 at 22:31
  • Looks like making an `auth.conf` file makes this work without entering a username/password in `virt-manager`: https://avdv.github.io/libvirt/auth.html Unfortunately this is not working in Terraform. – meustrus Jun 30 '22 at 01:54