Skip to main content
This article assumes you have already created virtual machines and covers common, secure ways to connect to them in Azure. We explain the typical connection patterns, OS/protocol/authentication options, and how to configure and use Azure Bastion to remotely manage VMs with private IPs. There are three common approaches to connecting to a virtual machine:
  • Public IP: Connect directly from an SSH or RDP client over the Internet when the VM has a public IP.
  • Jump box (bastion host): A VM with a public IP placed in a dedicated subnet. You SSH/RDP to the jump box, then from there connect to private VMs in the same virtual network.
  • Azure Bastion: A managed Azure service that provides secure, browser-based RDP/SSH access to VMs from the Azure portal. Bastion removes the need to create and manage a jump box VM and avoids exposing RDP/SSH ports to the Internet.
A network diagram titled "Connecting to Virtual Machines" illustrating connection options (Public IP, Jumpbox, Azure Bastion). It shows a virtual network with an Azure Bastion subnet containing a Bastion Host and Azure resource icons, and users connecting to VMs via the Bastion.
Prerequisites
  • An Azure subscription, resource group, and virtual network with subnets.
  • VMs deployed (Windows and/or Linux) and valid credentials or SSH keys.
  • Proper Network Security Group (NSG) rules as required for the chosen approach.
If you want to avoid exposing RDP/SSH to the public internet, plan to use a jump box or Azure Bastion. For production-scale deployments, consider placing Bastion in a hub VNet to serve multiple peered spokes.
OS / protocol / authentication options Example: SSH from a local terminal to a Linux VM with a public IP:
If a VM does not have a public IP, use a jump box or Azure Bastion to reach it securely. Deploying VMs for Bastion testing Below is an example PowerShell script used to create two VMs (one Windows, one Linux) in private subnets so you can test Bastion. Run this from Azure PowerShell or Cloud Shell after setting variables such as $rg, $region, $credential, and $VMsize.
After running the script, the VMs will appear in the portal without public IP addresses — ideal for demonstrating Bastion. Prepare the virtual network for Bastion Azure Bastion requires a dedicated subnet named AzureBastionSubnet. Create this subnet in the same virtual network that contains your VMs. The subnet should be large enough to accommodate Bastion’s requirements; commonly a /26 or larger is recommended, depending on scale.
A Microsoft Azure portal screenshot showing the "vnet-remoteaccess" virtual network Subnets page with existing "windows" and "linux" subnets. The Add subnet pane is open on the right with "AzureBastionSubnet" and address range 10.0.0.0/24 entered and the Save button highlighted.
Create the Bastion resource When creating the Bastion host in the Azure portal:
  • Select the same virtual network (e.g., vnet-remoteaccess).
  • Ensure a subnet named AzureBastionSubnet exists.
  • Create or select a Public IP for the Bastion host.
  • Choose the SKU (Basic or Standard). Basic is often sufficient for demos and is less costly; choose Standard for larger or production use.
Wait for deployment to complete after you submit the Bastion creation.
A Microsoft Azure portal screenshot showing a deployment overview for "Microsoft.BastionHost-20231210212032" with a green check and the message "Your deployment is complete." The page displays deployment details, subscription and resource group info, plus navigation and cost/security links.
Using Bastion to connect to private VMs Once Bastion is deployed, you can connect to virtual machines that only have private IPs via the Azure portal:
  1. Open the Virtual Machines list in the Azure portal and select the target VM.
  2. Click Connect → Bastion.
  3. Provide username and password (or use SSH key if the VM is configured for SSH keys).
  4. The portal will open an in-browser SSH session (for Linux) or an RDP session (for Windows).
A screenshot of the Microsoft Azure portal showing the "Virtual machines" blade with a list of virtual machines, their resource groups, locations, operating systems, sizes and public IP addresses. Several VMs are listed as "Running" with mostly Linux OS and one Windows VM.
Linux via Bastion: example in-browser SSH session Connecting to a Linux VM opens an interactive SSH terminal in your browser. Example login banner for an Ubuntu VM via Bastion:
From the in-browser SSH session you can run commands, update packages, and administer the system as you would from any SSH client. Windows via Bastion: in-browser RDP To connect to a Windows VM:
  1. Select the Windows VM and click Connect → Bastion.
  2. Enter valid Windows credentials.
  3. The Azure portal will open an RDP session in your browser. You’ll see the Windows sign-in screen and then the desktop after authentication.
A Windows sign-in screen with a circular user avatar and the username "kodekloud." Below it the message "Applying user settings" appears on a blue background inside a browser remote session.
Once connected over RDP through Bastion, you can administer the Windows server as usual.
A screenshot of the Windows Server Manager Dashboard (inside an Azure remote session) showing the "Configure this local server" page with a pop-up promoting Windows Admin Center and Azure Arc, and Local Server / All Servers status tiles visible.
Security considerations and hardening
  • Use NSGs to restrict inbound/outbound traffic to required management ports for jump boxes only.
  • Prefer SSH key authentication for Linux and Azure AD/managed identities where possible.
  • Limit who can create and use Bastion via RBAC and IAM policies.
  • Consider hosting Bastion in a centralized hub VNet to reduce deployment and cost overhead across multiple VNets.
Azure Bastion is a managed, secure way to connect to VMs from the browser without exposing RDP/SSH ports. Remember that Bastion requires a dedicated AzureBastionSubnet and incurs additional cost — consider placing Bastion in a hub VNet to serve multiple peered spokes instead of deploying Bastion in every VNet.
Useful references You can further harden and control remote access with Network Security Groups, role-based access controls, Just-In-Time VM access, and Azure Policy to enforce network/topology constraints.

Watch Video