[VMC on AWS] Enabling copy/paste between VMware Remote Console (VMRC) client and Virtual Machines.

Products

• VMware Cloud on AWS

Issue/Introduction

The purpose of this documentation is to address the query regarding enabling copy/paste between VMware Remote Console (VMRC) client and Virtual Machines.

Resolution

As vSphere switched away from Flash-based vCenter client to an HTML5-based client in version 6.5, the ability to copy and paste to and from virtual machines (VMs) through the console (WebMKS) has been removed as it is a major security liability: if any browser tab or background web process or script can intercept the clipboard of VMs anytime it is shared through the browser console, this causes data leak and possibly credentials leak.

As it stands with VMC on AWS and the versions of vSphere it uses, copy-paste is only possible through the VMRC client. It is considered the best practice is to use a Guest-supported method of transfer to exchange data with the VMs (standard file-transfer protocols, SSH/SCP/SFTP, and other remote access protocols like Remote Desktop Protocol (RDP), Virtual Network Computing (VNC), etc.), since clipboard sharing is considered as an unsecured channel.

VMRC connects differently than WebMKS. VMRC accesses the ESXi host directly to reach the VM, it does not go through the vCenter (acting as a proxy) as WebMKS does.

Refer KB57122 to enable the feature in the VM options 

Option 1: Direct Connect or a VPN can be set up to the management subnets of the SDDC so that all the management VMs and hosts can be directly accessed from the Intranet. It is detailed here:
Configure AWS Direct Connect Between Your SDDC and On-Premises Data Center: https://via.vmw.com/ET2N
Configure a VPN Connection Between Your SDDC and On-Premises Data Center https://via.vmw.com/ET2O

It is a secure, proven solution requiring some initial planning and setup though it tends to require little maintenance or changes once it is in place.

Option 2: A public access can be opened up towards few ports (TCP 443 and 902 + ICMP) to the ESX hosts, by getting Elastic-IPs(E-IPs) for each host and adding NAT rules to map these E-IPs to the ESX hosts' private IPs:
It is explained here:
Create or Modify NAT Rules: https://via.vmw.com/ET2R

NOTE: If filtering of, what traffic can the source IPs send to these ports (in the NAT rule setup and in any Management Gateway firewall inbound rules for the ESXi) is not done appropriately, then it might reduce the security of the SDDC unacceptably.

Finally, a Virtual Machine can be set up inside the SDDC to serve as a jump box, running VMRC there to access the ESX hosts directly. But this assumes that there needs to be some method to reach this VM from the outside, in the first place (so again, a public IP and NAT rule as with option 2).
This would however allow only to expose a specific remote access method of choice to the Internet (like RDP or SSH) and only requires one extra public IP.

The choice to choose the above two options will ultimately depend on how much data and how often it is to be exchanged with the VMs, along with the time remaining to finish setting up the servers and considering security.