I cannot change the security rule because that is managed by the org. I ended up killing the VMSS since nothing was working. Thanks for the help anyway
I have created a VMSS and cannot connect to the backend pool using ssh
All instances are healthy, and diagnostic does not find anything wrong.
Azure Virtual Machine Scale Sets
2 answers
Sort by: Most helpful
- 
				Matteo Interlandi 25 Reputation points Microsoft Employee2025-08-22T17:52:41.59+00:00 
- 
				Michele Ariis 6,255 Reputation points MVP2025-08-20T06:21:58.33+00:00 Hi, likely causes, fastest fixes: (1) How are you trying to SSH? A Load Balancer “backend pool” isn’t directly reachable, either use Bastion/private IP from a jump host, or expose SSH via the LB with Inbound NAT (per-instance) or an LB rule (not recommended for SSH). If you expect to hit the LB’s public IP, create an Inbound NAT pool mapping frontend ports (e.g., 50000-50099) → backend 22, attach it to the VMSS NIC config, then connect to ssh azureuser@<LB-PublicIP> -p <assignedPort> (get ports via az vmss list-instance-connection-info -g <rg> -n <vmss>). (2) NSGs/UDRs: With Standard LB the NSG must explicitly allow your client IP to TCP/22 on the VM NIC/subnet (the connection arrives with your real IP, not the service tag), and no UDR should blackhole return traffic. Don’t put a Deny above your allow-22 rule. (3) Public access disabled? If instances have no public IP and you didn’t set a NAT pool, you won’t reach them from the Internet; quickest path is Azure Bastion in the VNet or an internal jumpbox, then SSH to each VM’s private IP (az vmss nic list … to see them). (4) Guest OS firewall/SSH daemon: Ensure sshd is running/listening on 22 and distro firewall allows it (ufw status/firewall-cmd --list-ports); custom images often ship with SSH closed. (5) Auth mismatch: Use the exact username the image expects (e.g., azureuser) and the SSH key you configured for the VMSS; password auth may be disabled. (6) Health probe ≠ SSH: “Healthy” just means your probe port responded; it doesn’t prove 22 is reachable. (7) Quick triage: from a VM in the same VNet ssh <vm-private-ip>; if that works, it’s your edge/NAT/NSG; if not, it’s OS firewall/sshd/username/key. Easiest clean solution: enable Bastion (Standard tier), lock NSGs to deny 22 from Internet, and keep SSH private; if you must use the LB, add an Inbound NAT pool, allow 22 in NSGs from your office IPs, and verify with az vmss list-instance-connection-info.