Chapter 7. Remote virtual machines

Chapter 7. Remote virtual machines

• On Windows, you can use the Microsoft Terminal Services Connector (mstsc.exe) that ships with Windows. You can start it by bringing up the "Run" dialog (press the Windows key and "R") and typing "mstsc". You can also find it under "Start" → "All Programs" → "Accessories" → "Remote Desktop Connection". If you use the "Run" dialog, you can type in options directly:

  mstsc 1.2.3.4:3389

  Replace 1.2.3.4 with the host IP address, and 3389 with a different port if necessary.

  Note

  IPv6 address must be enclosed in square brackets to specify a port. For example: mstsc [fe80::1:2:3:4]:3389

  Note

  When connecting to localhost in order to test the connection, the addresses localhost and 127.0.0.1 might not work using mstsc.exe. Instead, the address 127.0.0.2[:3389] has to be used.

• On other systems, you can use the standard open-source rdesktop program. This ships with most Linux distributions, but VirtualBox also comes with a modified variant of rdesktop for remote USB support (see Section 7.1.4, “Remote USB” below).

  With rdesktop, use a command line such as the following:

  rdesktop -a 16 -N 1.2.3.4:3389

  As said for the Microsoft viewer above, replace 1.2.3.4 with the host IP address, and 3389 with a different port if necessary. The -a 16 option requests a color depth of 16 bits per pixel, which we recommend. (For best performance, after installation of the guest operating system, you should set its display color depth to the same value). The -N option enables use of the NumPad keys.

• If you run the KDE desktop, you might prefer krdc, the KDE RDP viewer. The command line would look like this:

  krdc rdp://1.2.3.4:3389

  Again, replace 1.2.3.4 with the host IP address, and 3389 with a different port if necessary. The "rdp://" bit is required with krdc to switch it into RDP mode.

• With Sun Ray thin clients you can use uttsc, which is part of the Sun Ray Windows Connector package. See the corresponding documentation for details.

• You can use

  VBoxManage startvm "VM name" --type headless

  The extra --type option causes VirtualBox to use VBoxHeadless as the front-end to the internal virtualization engine instead of the Qt front-end.

• One alternative is to use VBoxHeadless directly, as follows:

  VBoxHeadless --startvm <uuid|name>

  This way of starting the VM helps troubleshooting problems reported by VBoxManage startvm ... because you can see sometimes more detailed error messages, especially for early failures before the VM execution is started. In normal situations VBoxManage startvm is preferred since it runs the VM directly as a background process which has to be done explicitly when directly starting VBoxHeadless.

• The other alternative is to start VBoxHeadless from the VirtualBox Manager GUI, by holding the Shift key when starting a virtual machine or selecting Headless Start from the Machine menu.

1. VirtualBox on a server machine with a supported host operating system. The VirtualBox extension pack for the VRDP server must be installed (see the previous section). For the following example, we will assume a Linux server.

2. An ISO file accessible from the server, containing the installation data for the guest operating system to install (we will assume Windows XP in the following example).

3. A terminal connection to that host through which you can access a command line (e.g. via ssh).

4. An RDP viewer on the remote client; see Section 7.1.1, “Common third-party RDP viewers” above for examples.

1. On the headless server, create a new virtual machine:

   VBoxManage createvm --name "Windows XP" --ostype WindowsXP --register

   Note that if you do not specify --register, you will have to manually use the registervm command later.

   Note further that you do not need to specify --ostype, but doing so selects some sane default values for certain VM parameters, for example the RAM size and the type of the virtual network device. To get a complete list of supported operating systems you can use

   VBoxManage list ostypes

2. Make sure the settings for this VM are appropriate for the guest operating system that we will install. For example:

   VBoxManage modifyvm "Windows XP" --memory 256 --acpi on --boot1 dvd --nic1 nat

3. Create a virtual hard disk for the VM (in this case, 10 GB in size):

   VBoxManage createhd --filename "WinXP.vdi" --size 10000

4. Add an IDE Controller to the new VM:

   VBoxManage storagectl "Windows XP" --name "IDE Controller"
         --add ide --controller PIIX4

5. Set the VDI file created above as the first virtual hard disk of the new VM:

   VBoxManage storageattach "Windows XP" --storagectl "IDE Controller"
         --port 0 --device 0 --type hdd --medium "WinXP.vdi"

6. Attach the ISO file that contains the operating system installation that you want to install later to the virtual machine, so the machine can boot from it:

   VBoxManage storageattach "Windows XP" --storagectl "IDE Controller"
         --port 0 --device 1 --type dvddrive --medium /full/path/to/iso.iso

7. Enable VirtualBox remote desktop extension (the VRDP server):

   VBoxManage modifyvm "Windows XP" --vrde on

8. Start the virtual machine using VBoxHeadless:

   VBoxHeadless --startvm "Windows XP"

   If everything worked, you should see a copyright notice. If, instead, you are returned to the command line, then something went wrong.

9. On the client machine, fire up the RDP viewer and try to connect to the server (see Section 7.1.1, “Common third-party RDP viewers” above for how to use various common RDP viewers).

   You should now be seeing the installation routine of your guest operating system remotely in the RDP viewer.

• The "null" method means that there is no authentication at all; any client can connect to the VRDP server and thus the virtual machine. This is, of course, very insecure and only to be recommended for private networks.

• The "external" method provides external authentication through a special authentication library. VirtualBox ships with two such authentication libraries:

  1. The default authentication library, VBoxAuth, authenticates against user credentials of the hosts. Depending on the host platform, this means:

     • On Linux hosts, VBoxAuth.so authenticates users against the host's PAM system.

     • On Windows hosts, VBoxAuth.dll authenticates users against the host's WinLogon system.

     • On Mac OS X hosts, VBoxAuth.dylib authenticates users against the host's directory service.^[36]

     In other words, the "external" method per default performs authentication with the user accounts that exist on the host system. Any user with valid authentication credentials is accepted, i.e. the username does not have to correspond to the user running the VM.

  2. An additional library called VBoxAuthSimple performs authentication against credentials configured in the "extradata" section of a virtual machine's XML settings file. This is probably the simplest way to get authentication that does not depend on a running and supported guest (see below). The following steps are required:

     1. Enable VBoxAuthSimple with the following command:

        VBoxManage setproperty vrdeauthlibrary "VBoxAuthSimple"

     2. To enable the library for a particular VM, you must then switch authentication to external:

        VBoxManage modifyvm "VM name" --vrdeauthtype external

        Replace <vm> with the VM name or UUID.

     3. You will then need to configure users and passwords by writing items into the machine's extradata. Since the XML machine settings file, into whose "extradata" section the password needs to be written, is a plain text file, VirtualBox uses hashes to encrypt passwords. The following command must be used:

        VBoxManage setextradata "VM name" "VBoxAuthSimple/users/<user>" <hash>

        Replace <vm> with the VM name or UUID, <user> with the user name who should be allowed to log in and <hash> with the encrypted password. As an example, to obtain the hash value for the password "secret", you can use the following command:

        VBoxManage internalcommands passwordhash "secret"

        This will print

        2bb80d537b1da3e38bd30361aa855686bde0eacd7162fef6a25fe97bf527a25b

        You can then use VBoxManage setextradata to store this value in the machine's "extradata" section.

        As example, combined together, to set the password for the user "john" and the machine "My VM" to "secret", use this command:

        VBoxManage setextradata "My VM" "VBoxAuthSimple/users/john"
            2bb80d537b1da3e38bd30361aa855686bde0eacd7162fef6a25fe97bf527a25b

• Finally, the "guest" authentication method performs authentication with a special component that comes with the Guest Additions; as a result, authentication is not performed on the host, but with the guest user accounts.

  This method is currently still in testing and not yet supported.

1. Historically, RDP4 authentication was used, with which the RDP client does not perform any checks in order to verify the identity of the server it connects to. Since user credentials can be obtained using a "man in the middle" (MITM) attack, RDP4 authentication is insecure and should generally not be used.

2. RDP5.1 authentication employs a server certificate for which the client possesses the public key. This way it is guaranteed that the server possess the corresponding private key. However, as this hard-coded private key became public some years ago, RDP5.1 authentication is also insecure.

3. RDP5.2 authentication uses the Enhanced RDP Security, which means that an external security protocol is used to secure the connection. RDP4 and RDP5.1 use Standard RDP Security. The VRDP server supports Enhanced RDP Security with TLS protocol and, as a part of TLS handshake, sends the server certificate to the client.

   The Security/Method VRDE property sets the desired security method, which is used for a connection. Valid values are:

   • Negotiate - both Enhanced (TLS) and Standard RDP Security connections are allowed. The security method is negotiated with the client. This is the default setting.

   • RDP - only Standard RDP Security is accepted.

   • TLS - only Enhanced RDP Security is accepted. The client must support TLS.

   For example the following command allows a client to use either Standard or Enhanced RDP Security connection:

   vboxmanage modifyvm "VM name" --vrdeproperty "Security/Method=negotiate"

   If the Security/Method property is set to either Negotiate or TLS, the TLS protocol will be automatically used by the server, if the client supports TLS. However, in order to use TLS the server must possess the Server Certificate, the Server Private Key and the Certificate Authority (CA) Certificate. The following example shows how to generate a server certificate.

   1. Create a CA self signed certificate:

      openssl req -new -x509 -days 365 -extensions v3_ca \
        -keyout ca_key_private.pem -out ca_cert.pem

   2. Generate a server private key and a request for signing:

      openssl genrsa -out server_key_private.pem
      openssl req -new -key server_key_private.pem -out server_req.pem

   3. Generate the server certificate:

      openssl x509 -req -days 365 -in server_req.pem \
        -CA ca_cert.pem -CAkey ca_key_private.pem -set_serial 01 -out server_cert.pem

   The server must be configured to access the required files:

   vboxmanage modifyvm "VM name" \
     --vrdeproperty "Security/CACertificate=path/ca_cert.pem"

   vboxmanage modifyvm "VM name" \
     --vrdeproperty "Security/ServerCertificate=path/server_cert.pem"

   vboxmanage modifyvm "VM name" \
     --vrdeproperty "Security/ServerPrivateKey=path/server_key_private.pem"