Configuring protocols

You can configure the SSH protocol to remotely monitor a host.

1. Log in to host A with the same user ID that runs the Linux KVM agent process, for example, the root user ID.
   Tip: Ensure that you know the ID on host B that accepts the SSH connection and the root user ID on host A.
2. Generate the id_rsa and id_rsa.pub keys on host A by using the ssh-keygen utility.
   The keys are saved at the following location: ~/.ssh: $ ssh-keygen -t rsa.
3. Copy the authorized keys from host B:

   $ scp Id on host B@name or IP address of host B:~/.ssh/authorized_keys ~/.ssh/authorized_keys_from_B

4. Append the public key for host A to the end of the authorized keys for host B:

   cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys_from_B

5. Copy the authorized keys back to host B:

   $ scp ~/.ssh/authorized_keys_from_B Id on host B@name or IP address of host B:~/.ssh/authorizede_keys

   Remember: If you are monitoring multiple hosts, repeat steps 3, 4, and 5 for each host.
6. Remove the authorized keys that you copied on host B:

   ~/.ssh/authorized_keys_from_B

7. Add the following command to the ~/.bash_ profile of the current ID on host A:

   $ eval `ssh-agent`

   Remember: Ensure that you use the single back quotation mark (`) that is located under the tilde (~) on US keyboards, rather than the single quotation mark (').
8. Add the identity to host A and enter the password that you used when you created the ID:

   $ ssh-add ~/.ssh/id_rsa

9. Run the following command if you receive the Could not open a connection to your authentication agent message:

   exec ssh-agent bash

   Tip: You can replace the bash with the shell that you are using and then run the following command again:

   $ ssh-add ~/.ssh/id_rsa

10. Test the SSH protocol to ensure that it connects from host A to host B without entering the SSH password:
    Tip: If you are monitoring multiple hosts, use the following command to test the connection for each host:

    $ ssh Id on host B@name or IP address of host B

11. To verify the connection, run the following command:

    virsh -c qemu+ssh://Id on host B@name or IP address of host B:port/system

    If you did not change the default SSH port, omit the :port section of the command.

    Important: If the virsh command succeeds, the Linux KVM agent connects to the hypervisor.
12. You must restart host A before you restart the Linux KVM agent on host A. To restart, run the ssh-add command again and specify the password each time.
    Tip: You can use SSH keychains to avoid reentering the password.

You can configure the TLS protocol to remotely monitor a host.

1. To create a certificate authority (CA) key and a certificate in your hypervisor, complete the following steps:
   1. Log in to host B.
   2. Create a temporary directory and change the path to this temporary directory:

      mkdir cert_files

      cd cert_files

   3. Create a 2048-bit RSA key:

      openssl genrsa -out cakey.pem 2048

   4. Create a self-signed certificate to your local CA:

      openssl req -new -x509 -days 1095 -key cakey.pem -out \
      cacert.pem -sha256 -subj "/C=US/L=Austin/O=IBM/CN=my CA"

   5. Check your CA certificate:

      openssl x509 -noout -text -in cacert.pem

2. To create the client and server keys and certificates in your hypervisor, complete the following steps:
   1. Create the keys:

      openssl genrsa -out serverkey.pem 2048

      openssl genrsa -out clientkey.pem 2048

   2. Create a certificate signing request for the server:
      Remember: Change the kvmhost.company.org address, which is used in the server certificate request, to the fully qualified domain name of your hypervisor host.

      openssl req -new -key serverkey.pem -out serverkey.csr \
      -subj "/C=US/O=IBM/CN=kvmhost.company.org"

   3. Create a certificate signing request for the client:

      openssl req -new -key clientkey.pem -out clientkey.csr \
      -subj "/C=US/O=IBM/OU=virtualization/CN=root"

   4. Create client and server certificates:

      openssl x509 -req -days 365 -in clientkey.csr -CA cacert.pem \
      -CAkey cakey.pem -set_serial 1 -out clientcert.pem

      openssl x509 -req -days 365 -in serverkey.csr -CA cacert.pem \
      -CAkey cakey.pem -set_serial 94345 -out servercert.pem

   5. Check the keys:

      openssl rsa -noout -text -in clientkey.pem

      openssl rsa -noout -text -in serverkey.pem

   6. Check the certificates:

      openssl x509 -noout -text -in clientcert.pem

      openssl x509 -noout -text -in servercert.pem

3. To distribute the keys and certificates to the host server, complete the following steps:
   1. Copy the CA certificate cacert.pem file to this directory: /etc/pki/CA

      cp cacert.pem /etc/pki/CA/cacert.pem

   2. Create the /etc/pki/libvirt directory, and copy the servercert.pem server certificate file to the /etc/pki/libvirt directory. Ensure that only the root user can access the private key.

      mkdir /etc/pki/libvirt

      cp servercert.pem /etc/pki/libvirt/.

      chmod -R o-rwx /etc/pki/libvirt

      Remember: If the keys or certificates are named incorrectly or copied to the wrong directories, the authorization fails.
   3. Create the /etc/pki/libvirt/private directory and copy the serverkey.pem server key file to the /etc/pki/libvirt/private directory. Ensure that only the root user can access the private key.

      mkdir /etc/pki/libvirt/private

      cp serverkey.pem /etc/pki/libvirt/private/.

      chmod -R o-rwx /etc/pki/libvirt/private

      Remember: If the keys or certificates are named incorrectly or copied to the wrong directories, the authorization fails.
   4. Verify that the files are correctly placed:

      find /etc/pki/CA/*|xargs ls -l

      ls -lR /etc/pki/libvirt

      ls -lR /etc/pki/libvirt/private

      Remember: If the keys or certificates are named incorrectly or copied to the wrong directories, the authorization fails.
4. To distribute keys and certificates to clients or management stations, complete the following steps:
   1. Log in to host A.
   2. Copy the CA certificate cacert.pem from the host to the /etc/pki/CA directory in host A without changing the file name.

      scp kvmhost.company.org:/tmp/cacert.pem /etc/pki/CA/

   3. Copy the client certificate clientcert.pem file to the /etc/pki/libvirt directory from host B. Use the default file names and make sure that only the root user is able to access the private key.

      mkdir /etc/pki/libvirt/

      scp kvmhost.company.org:/tmp/clientcert.pem /etc/pki/libvirt/.

      chmod -R o-rwx /etc/pki/libvirt

      Remember: If the keys or certificates are named incorrectly or copied to the wrong directories, the authorization fails.
   4. Copy the client key clientkey.pem to the /etc/pki/libvirt/private directory from the host. Use the default file names and ensure that only the root user can access the private key.

      mkdir /etc/pki/libvirt/private

      scp kvmhost.company.org:/tmp/clientkey.pem /etc/pki/libvirt/private/.

      chmod -R o-rwx /etc/pki/libvirt/private

      Remember: If the keys or certificates are named incorrectly or copied to the wrong directories, the authorization fails.
   5. Verify that the files are correctly placed:

      ls -lR /etc/pki/libvirt

      ls -lR /etc/pki/libvirt/private

5. To edit the libvirtd daemon configuration, complete the following steps:
   1. Log in to host B.
   2. Make a copy of the /etc/sysconfig/libvirtd file and the /etc/libvirt/libvirtd.conf file.
   3. Edit the /etc/sysconfig/libvirtd file and ensure that the --listen parameter is passed to the libvirtd daemon. This step ensures that the libvirtd daemon is listening to network connections.
   4. Edit the /etc/libvirt/libvirtd.conf file and configure a set of allowed subjects with the tls_allowed_dn_list directive in the libvirtd.conf file.
      Important: The fields in the subject must be in the same order that you used to create the certificate.
   5. Restart the libvirtd daemon service for changes to take effect:

      /etc/init.d/libvirtd restart

6. To change the firewall configuration, access the security level configuration and add TCP port 16514 as a trusted port.
7. To verify that the remote management is working, run the following command on host A:

   virsh -c qemu+tls://kvmhost.company.org/system list --all

Use the TCP protocol only for testing.

1. Log in to host B.
2. Edit the /etc/libvirt/libvirtd.conf file and ensure that the listen_tcp parameter is enabled, and the value of the tcp_port parameter is set to the default value of 16509.
3. Edit the /etc/libvirt/libvirtd.conf file to set the auth_tcp parameter to none. This step instructs TCP not to authenticate the connection.
4. Restart the libvirt daemon on host B in listening mode by running it with the --listen flag or by editing the /etc/sysconfig/libvirtd file and uncommenting the LIBVIRTD_ARGS="--listen" line.
5. To verify the connection, run the following command:

   virsh -c qemu+tcp://kvmhost.company.org:port/system

   If you did not change the default TCP port, omit the :port section of the command.

   Important: If the virsh command succeeds, the Linux KVM agent connects to the hypervisor.