Exposing an administrative VM's SSH port to the internet may be undesirable. But how do you connect after removing the VM's public IP? Azure Bastion provides a management path between the administrator and the VM. The key distinction is that the target VM need not have its own public IP; it does not mean every public-facing connection point disappears.
What path does a browser connection take?
The diagram separates the Bastion entry point from the target VM's private IP. In a portal-based session, the browser reaches Bastion over HTTPS; Bastion reaches the VM through its virtual network using SSH or RDP.
Suppose a Linux VM has only a private IP in a VNet. An administrator opens its Bastion connection in the Azure portal and authenticates. A simplified route is:
Administrator browser ─ HTTPS ─> Bastion service
└─ private VNet SSH path ─> target VMWithout a public IP on the VM, there is no direct internet route to that VM's port 22 through its own public address. Bastion still has its own access point. Do not read “no public IP on the VM” as “no public network endpoint anywhere.” Bastion SKU and configuration requirements can change, so check the current product settings before deployment.
Where should you look when a connection fails?
First, can the administrator open a Bastion session in the portal? User permissions, Bastion deployment state, and the browser-to-service path matter here. Second, does the session open but VM login fail? Check the VM account, SSH key or password, and guest SSH/RDP service. Third, can Bastion reach the VM's private IP through the network rules?
| Observation | Boundary to check first |
|---|---|
| Bastion connection page does not open | Administrator access, service state, Bastion entry path |
| Page opens but VM connection times out | VNet route, VM private IP, NSG, guest firewall |
| VM responds but login fails | VM account, SSH key, RDP credentials |
This table helps locate a failing segment; it does not diagnose every cause. Opening SSH from the entire internet because a port is blocked defeats the purpose of the Bastion path. Restrict the VM's SSH/RDP access to the intended route. Bastion itself also needs its required NSG rules; see the current Azure Bastion NSG guidance.
What security benefit remains, and what responsibilities remain?
Removing the VM's public IP and direct internet-facing management port reduces direct exposure of the VM. It does not fix a stolen administrator account, excessive permissions, weak guest authentication, or overly broad private-network rules. Limit access to the administrators who need it and review connection records.
Bastion is a managed service with cost and dedicated network requirements. Keeping it enabled for a single small exercise and using it as a shared path for many VMs are different decisions. The diagram and table are explanatory examples, not a claim that this configuration was deployed successfully in an actual Azure account.
Key takeaways: the VM and management entry point are different
Azure Bastion can provide SSH or RDP access over a private path without assigning a public IP to the target VM. Troubleshoot browser → Bastion, Bastion → VM, and VM authentication separately. Closing direct public VM ports and maintaining safe administrator permissions and private-network rules go together.
