We are friends with virt-manager with a remote system on top of tls
At work, we actively use virtualization based on qemu / kvm via libvirt . I myself moved to linux a long time ago and also use qemu / kvm on my local machine, and often use the graphical virt-manager to configure various VM parameters. I wanted to use it to manage hypervisors on remote servers. An article about how to do this will be an article in the form of step-by-step instructions (in fact, this is translation and “consolidation” of official documentation).
It is implied that all actions are done on the “virtualization node” (where libvirtd stands, in this case CentOS 6) and selinux is disabled. Perform in the console:
Create a template with root certificate parameters (CA):
')
We generate the secret key for CA:
Generating self-signed CA:
Create a template with the certificate settings for the "virtualization node":
We generate the secret key for the “virtualization node”:
We generate a certificate for our "virtualization node":
Create a template with the certificate settings for the client:
We generate the secret key for the client:
We generate a certificate for the client:
All of the steps below must be done either through sudo or as the root user:
Permissions 640 on to server-key.pem are needed in order to be able to use the same key for vnc connections, with this the virt-pki-validate utility will swear that the rights should be 600- ignored.
All of the steps below must be done either through sudo or as the root user:
In the file /etc/libvirt/libvirtd.conf, the following values ​​should be set for the corresponding parameters:
As a result, we will enable tls and configure logging.
In tls_allowed_dn_list, it is prescribed dn (Distinguished Name) certificates that can connect to libvirtd
In the / etc / sysconfig / libvirtd file, the LIBVIRTD_ARGS parameter should be set to “--listen”:
In the /etc/libvirt/qemu.conf file, the following values ​​should be set for the corresponding parameters:
So we will enable tls to connect virtual machines via vnc, disable audio transmission (we don’t need it, if you need, leave enabled), enable compression for snapshots of memory (useful for live backups, if you are interested, we back it up so , as before laid out there, I bring in the form of the link), and also we will include the corresponding cgroups groups (in general it is included by default, but rigidly set)
Only after this edit, restart libvirtd:
For already running virtual machines, connecting via vnc over tls will be possible only after turning them off and on again (virsh shutdown / start)
To connect to libvirtd and vnc in the INPUT chain, you need to make the following rules (if you use iptables):
This implies that vnc consoles will be whistled on ports from 5900 to 6000. After that, save the current iptables rules with the command:
In this case, perform all the points except 1. and 2., while indicating your path to the root certificate and its key in the appropriate parameters (- load-ca-certificat, --load-ca-privkey), skip if necessary 4. if certificates are already generated for the required clients.
Linux means Centos / Fedora in this case.
It is executed on a remote system from which the virtualization nodes will be administered.
First you need to create folders for the corresponding certificates:
Next, put the appropriate files from the server along the required paths on the local machine with which the connection will occur:
/tmp/certs/ca/certificate_authority_certificate.pem put in /etc/pki/CA/cacert.pem
/tmp/certs/client/client_key.pem put in /etc/pki/libvirt/private/clientkey.pem
/tmp/certs/client/client_certificate.pem put in /etc/pki/libvirt/clientcert.pem
With such settings, local users in the wheel group and the root user can connect to libvirtd / vnc on the remote server.
IMPORTANT! server.name here is exactly the name that we specified when generating the certificate for “virtualization nodes” (certificate field cn), it must be correctly defined in the ip on the client.
In virt-manager, select the type of connection- “ssl / tls with certificates”, the username is empty, the hostname is server.name, which was mentioned above.
virt-viewer -c qemu + tls: //server.name/system log_name
It is executed on a remote system from which the virtualization nodes will be administered.
You can connect via:
I could not get to work
For ssvnc, the client's key and certificate should be in the same file, you can do it this way (it is assumed that you are on the server where the certificates were originally generated):
We take from the server the resulting client.pem and /tmp/certs/ca/certificate_authority_certificate.pem
Run ssvnc- in the main window, put “Use SSL”, click “Certs” in “MyCerts”, specify the path to client.pem, in “ServerCert” specify the path to certificate_authority_certificate.pem, then click “Options” -> “Advanced” and set a tick opposite to "Server uses Vencrypt ssl encryption". In the main window, in the “Vnc Host: Display” field, specify the server address and the vnc port number, respectively. Click "Connect".
As a result, we can manage our virtual machines locally via virsh, virt-manager (only those functions that are supported by the server are available). The disadvantages of this solution are that the remote control of the VM is not displayed in the logs (or I did not manage to achieve this), it will not be seen in the logs that switching off / etc has initialized such and such a user from such an ip.
wiki.libvirt.org/page/TLSSetup
wiki.libvirt.org/page/VNCTLSSetup
As noted in the comments, you can connect over ssh c without-password for root (adding a user to the centos libvirt group is not applicable), yes, but at the same time vnc will go directly and you can “look at the screen”, in this case, you can also use ssh tunnels for vnc.
Personally, it is easier to configure and use once, than to raise ssh tunnels every time.
Training
It is implied that all actions are done on the “virtualization node” (where libvirtd stands, in this case CentOS 6) and selinux is disabled. Perform in the console:
mkdir /tmp/certs cd /tmp/certs We generate the self-signed root certificate
mkdir ca cd ca Create a template with root certificate parameters (CA):
')
cat > certificate_authority_template.info << 'EOF' cn = Name of your organization ca cert_signing_key expiration_days = 3650 EOF “Name of your organization” - respectively, the name of your organization in Latin, the certificate is valid for 10 years.We generate the secret key for CA:
(umask 277 && certtool --generate-privkey > certificate_authority_key.pem) Generating self-signed CA:
certtool --generate-self-signed \ --template certificate_authority_template.info \ --load-privkey certificate_authority_key.pem \ --outfile certificate_authority_certificate.pem We generate a certificate for “virtualization nodes” (where libvirtd is located)
cd .. mkdir kvm_host cd kvm_host Create a template with the certificate settings for the "virtualization node":
cat > host_server_template.info << 'EOF' organization = Name of your organization cn = server.name tls_www_server encryption_key signing_key EOF "Server.name" is the dns name of the "virtualization node" for which the certificate is generated,We generate the secret key for the “virtualization node”:
(umask 277 && certtool --generate-privkey > host_server_key.pem) We generate a certificate for our "virtualization node":
certtool --generate-certificate \ --template host_server_template.info \ --load-privkey host_server_key.pem \ --load-ca-certificate ../ca/certificate_authority_certificate.pem \ --load-ca-privkey ../ca/certificate_authority_key.pem \ --outfile host_server_certificate.pem We generate the certificate for client connection.
cd .. mkdir client cd client Create a template with the certificate settings for the client:
cat > client_template.info << 'EOF' country = RU state = State locality = City organization = Name of your organization cn = client.host tls_www_client encryption_key signing_key EOF "Client.host" - dns the client name, state and locality fill in at your discretion.We generate the secret key for the client:
(umask 277 && certtool --generate-privkey > client_key.pem) We generate a certificate for the client:
certtool --generate-certificate \ --template client_template.info \ --load-privkey client_key.pem \ --load-ca-certificate ../ca/certificate_authority_certificate.pem \ --load-ca-privkey ../ca/certificate_authority_key.pem \ --outfile client_certificate.pem Connecting certificates / keys to libvirt
cd /tmp/certs All of the steps below must be done either through sudo or as the root user:
mkdir -p /etc/pki/libvirt/private chmod 755 /etc/pki/libvirt chmod 750 /etc/pki/libvirt/private cp ./ca/certificate_authority_certificate.pem /etc/pki/libvirt/cacert.pem cp ./kvm_host/host_server_certificate.pem /etc/pki/libvirt/servercert.pem cp ./kvm_host/host_server_key.pem /etc/pki/libvirt/private/serverkey.pem ln -s /etc/pki/libvirt/cacert.pem /etc/pki/CA/ chgrp qemu /etc/pki/libvirt \ /etc/pki/libvirt/servercert.pem \ /etc/pki/libvirt/private \ /etc/pki/libvirt/private/serverkey.pem chmod 440 /etc/pki/libvirt/servercert.pem chmod 444 /etc/pki/libvirt/cacert.pem chmod 640 /etc/pki/libvirt/private/serverkey.pem Permissions 640 on to server-key.pem are needed in order to be able to use the same key for vnc connections, with this the virt-pki-validate utility will swear that the rights should be 600- ignored.
Connecting certificates / keys to vnc
All of the steps below must be done either through sudo or as the root user:
mkdir /etc/pki/libvirt-vnc ln -s /etc/pki/libvirt/cacert.pem /etc/pki/libvirt-vnc/ca-cert.pem ln -s /etc/pki/libvirt/servercert.pem /etc/pki/libvirt-vnc/server-cert.pem ln -s /etc/pki/libvirt/private/serverkey.pem /etc/pki/libvirt-vnc/server-key.pem chgrp qemu /etc/pki/libvirt-vnc chmod 750 /etc/pki/libvirt-vnc Configure the libvirtd daemon
In the file /etc/libvirt/libvirtd.conf, the following values ​​should be set for the corresponding parameters:
listen_tls = 1 tls_port = "16514" auth_tls = "none" key_file = "/etc/pki/libvirt/private/serverkey.pem" cert_file = "/etc/pki/libvirt/servercert.pem" ca_file = "/etc/pki/libvirt/cacert.pem" crl_file = "/etc/pki/libvirt/crl.pem" #tls_allowed_dn_list = ["DN1", "DN2"] log_level = 3 log_outputs="4:syslog:libvirtd 3:file:/var/log/libvirt/libvirt.log" audit_level = 2 audit_logging = 1 keepalive_interval = 5 keepalive_count = 5 As a result, we will enable tls and configure logging.
In tls_allowed_dn_list, it is prescribed dn (Distinguished Name) certificates that can connect to libvirtd
In the / etc / sysconfig / libvirtd file, the LIBVIRTD_ARGS parameter should be set to “--listen”:
LIBVIRTD_ARGS="--listen" Configure the qemu / kvm daemon
In the /etc/libvirt/qemu.conf file, the following values ​​should be set for the corresponding parameters:
vnc_tls = 1 vnc_tls_x509_verify = 1 vnc_allow_host_audio = 0 cgroup_controllers = [ "cpu", "devices", "memory", "blkio", "cpuset", "cpuacct" ] save_image_format = "lzop" clear_emulator_capabilities = 1 So we will enable tls to connect virtual machines via vnc, disable audio transmission (we don’t need it, if you need, leave enabled), enable compression for snapshots of memory (useful for live backups, if you are interested, we back it up so , as before laid out there, I bring in the form of the link), and also we will include the corresponding cgroups groups (in general it is included by default, but rigidly set)
Only after this edit, restart libvirtd:
service libvirtd restart For already running virtual machines, connecting via vnc over tls will be possible only after turning them off and on again (virsh shutdown / start)
Iptables configuration
To connect to libvirtd and vnc in the INPUT chain, you need to make the following rules (if you use iptables):
iptables -I INPUT -m state --state NEW -m tcp -p tcp --dport 16514 -j ACCEPT iptables -I INPUT -m state --state NEW -s 192.168.40.0/24 -m tcp -p tcp --dport 5900:6000 -j ACCEPT This implies that vnc consoles will be whistled on ports from 5900 to 6000. After that, save the current iptables rules with the command:
iptables-save>/etc/sysconfig/iptables If you already have a self-signed root certificate / client certificates
In this case, perform all the points except 1. and 2., while indicating your path to the root certificate and its key in the appropriate parameters (- load-ca-certificat, --load-ca-privkey), skip if necessary 4. if certificates are already generated for the required clients.
Client Setup (Linux)
Linux means Centos / Fedora in this case.
It is executed on a remote system from which the virtualization nodes will be administered.
First you need to create folders for the corresponding certificates:
mkdir -m 750 -p /etc/pki/libvirt/private mkdir -m 700 ~/.pki/libvirt-vnc Next, put the appropriate files from the server along the required paths on the local machine with which the connection will occur:
/tmp/certs/ca/certificate_authority_certificate.pem put in /etc/pki/CA/cacert.pem
/tmp/certs/client/client_key.pem put in /etc/pki/libvirt/private/clientkey.pem
/tmp/certs/client/client_certificate.pem put in /etc/pki/libvirt/clientcert.pem
chmod 444 /etc/pki/CA/cacert.pem chmod 440 /etc/pki/libvirt/clientcert.pem \ /etc/pki/libvirt/private/clientkey.pem chown -R root:wheel /etc/pki/libvirt cd ~/.pki/libvirt-vnc/ ln -s /etc/pki/libvirt/clientcert.pem clientcert.pem ln -s /etc/pki/libvirt/private/clientkey.pem clientkey.pem With such settings, local users in the wheel group and the root user can connect to libvirtd / vnc on the remote server.
Example:
virsh:
virsh -c qemu+tls://server.name/system, virsh -c qemu+tls://kvm_server.local/system IMPORTANT! server.name here is exactly the name that we specified when generating the certificate for “virtualization nodes” (certificate field cn), it must be correctly defined in the ip on the client.
Virt-manager:
In virt-manager, select the type of connection- “ssl / tls with certificates”, the username is empty, the hostname is server.name, which was mentioned above.
Virt-viewer:
virt-viewer -c qemu + tls: //server.name/system log_name
Configuring the client (Windows, only access to the vnc console)
It is executed on a remote system from which the virtualization nodes will be administered.
You can connect via:
virt-viewer
I could not get to work
ssvnc
For ssvnc, the client's key and certificate should be in the same file, you can do it this way (it is assumed that you are on the server where the certificates were originally generated):
cd /tmp/certs/client cat client_certificate.pem client_key.pem >client.pem We take from the server the resulting client.pem and /tmp/certs/ca/certificate_authority_certificate.pem
Run ssvnc- in the main window, put “Use SSL”, click “Certs” in “MyCerts”, specify the path to client.pem, in “ServerCert” specify the path to certificate_authority_certificate.pem, then click “Options” -> “Advanced” and set a tick opposite to "Server uses Vencrypt ssl encryption". In the main window, in the “Vnc Host: Display” field, specify the server address and the vnc port number, respectively. Click "Connect".
Result:
As a result, we can manage our virtual machines locally via virsh, virt-manager (only those functions that are supported by the server are available). The disadvantages of this solution are that the remote control of the VM is not displayed in the logs (or I did not manage to achieve this), it will not be seen in the logs that switching off / etc has initialized such and such a user from such an ip.
Related Links
wiki.libvirt.org/page/TLSSetup
wiki.libvirt.org/page/VNCTLSSetup
Upd
As noted in the comments, you can connect over ssh c without-password for root (adding a user to the centos libvirt group is not applicable), yes, but at the same time vnc will go directly and you can “look at the screen”, in this case, you can also use ssh tunnels for vnc.
Personally, it is easier to configure and use once, than to raise ssh tunnels every time.
Source: https://habr.com/ru/post/221693/
All Articles