dmacvicar / terraform-provider-libvirt

Terraform provider to provision infrastructure with Linux's KVM using libvirt
Apache License 2.0
1.54k stars 457 forks source link

SSH hostkeys other than sk-* are rejected #915

Closed sspreitzer closed 2 years ago

sspreitzer commented 2 years ago

System Information

Linux distribution

Client: Gentoo Server: RHEL 7.7

Terraform version

[sspreitzer@voyager k8s]$ terraform -v
Terraform v1.0.0
on linux_amd64
+ provider registry.terraform.io/dmacvicar/libvirt v0.6.12
+ provider registry.terraform.io/hashicorp/null v3.1.0

Your version of Terraform is out of date! The latest version
is 1.1.2. You can update by downloading from https://www.terraform.io/downloads.html

Description of Issue/Question

When running terraform plan on the client, the client produces:

[sspreitzer@voyager k8s]$ terraform plan
╷
│ Error: failed to dial libvirt: failed to connect to libvirt on the remote host: ssh: rejected: administratively prohibited (open failed)
│ 
│   with provider["registry.terraform.io/dmacvicar/libvirt"],
│   on libvirt-provider.tf line 11, in provider "libvirt":
│   11: provider "libvirt" {
│ 
╵

The provider config is:

provider "libvirt" {
    uri = "qemu+ssh://root@10.1.1.2/system?keyfile=/home/sspreitzer/.ssh/id_rsa&sshauth=privkey"
}

The server log is reporting:

Dez 20 15:44:48 vm2.zh.spreitzer.ch sshd[15463]: Unable to negotiate with 10.1.1.100 port 34390: no matching host key type found. Their offer: sk-ecdsa-sha2-nistp256@openssh.com [preauth]
Dez 20 15:44:48 vm2.zh.spreitzer.ch sshd[15461]: Unable to negotiate with 10.1.1.100 port 34392: no matching host key type found. Their offer: sk-ssh-ed25519@openssh.com [preauth]

SSH version installed is the latest ssh version available for RHEL 7 (7.9):

[root@vm2 ~]# rpm -qa|grep -i openssh-server
openssh-server-7.4p1-22.el7_9.x86_64

Conclusion is, that the builtin ssh client of the plugin is not supporting the servers rsa,dsa,ecdsa and ed25519 hostkeys. The ssh server version is not capable of producing and using sk-* hostkeys.

Suggestion is to make the hostkey type acceptance configurable or compatible to rsa, dsa, ecdsa and ed25519. Otherwise many server systems will be excluded from being usable.

sspreitzer commented 2 years ago

Notably: https://pkg.go.dev/golang.org/x/crypto/ssh#ClientConfig.HostKeyAlgorithms

sspreitzer commented 2 years ago

ping @dmacvicar

sspreitzer commented 2 years ago

I do not not understand how, but this problem does no longer exist.

The server side permission problem however was solved by using a non-root user who is part of the libvirt group to access the libvirt socket on the server. Apparently some OpenSSH servers are compiled with the restriction, that root may never be able to forward ports/sockets.

Creating a user virt, being part of group libvirt solved the problem. The ssh key was copied to the virt user on the target server.

/etc/libvirt/libvirtd.conf on the server (needs restart of libvirt daemon):

# This is restricted to 'root' by default.
unix_sock_group = "libvirt"

Effects:

[sspreitzer@voyager k8s]$ ssh virt@10.1.1.2
Last login: Sun Jan  2 13:53:33 2022 from 10.1.1.100
[virt@vm2 ~]$ id
uid=1000(virt) gid=1000(virt) groups=1000(virt),992(libvirt) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
[virt@vm2 ~]$ ls -al /var/run/libvirt/libvirt-sock
srwxrwx---. 1 root libvirt 0  8. Jul 08:12 /var/run/libvirt/libvirt-sock

The provider config:

provider "libvirt" {
    uri = "qemu+ssh://virt@10.1.1.2/system"
}
dmacvicar commented 2 years ago

Perhaps we should document this.