Open nturinski opened 3 years ago
@nturinski
It probably isn't worth implementing this due to the limitation of not being able to connect to VM's via private IP unless you are within the same virtual network.
This assumption does not hold true in many cases, especially in corporate environments where users connect to their Azure VNets from within the company network over VPNs, virtual network gateways, etc.
In order to support private IP addresses, we'll have to attach the VM to a public NIC and use that to connect to the VM.
Given the above corporate network scenario, this requirement is not necessary. The only requirement for the SSH connection to work is for the VM's private IP to be routable from the user's network.
As it stands, this extension is likely not useful for the majority of users in corporate environments, especially those with strict regulatory compliance requirements. This limitation may be causing confusion and other issue reports. For example, I can reproduce #219 because of the public IP assumption.
Would adding an opt-in setting such as azureVirtualMachines.showAdvancedOptions
or similar make sense? Any users who enable that setting (or who are instructed to do so by their DevOps platform team, for example) would see additional commands like Create Virtual Machine (Advanced, Private IP)
, Copy IP Address (Advanced, Private IP)
, and Connect to Host via Remote SSH (Advanced, Private IP)
. Perhaps some type of warning message or popup could accompany the opt-in for that setting to reduce any confusion from accidental use (e.g., "only enable this if you know what you are doing!").
From: https://github.com/microsoft/vscode-azurevirtualmachines/pull/264
Today, we can only remote into a VM if it has a public IP address. In order to support private IP addresses, we'll have to attach the VM to a public NIC and use that to connect to the VM.