I have created a VMSS and cannot connect to the backend pool using ssh

Matteo Interlandi 25 Reputation points Microsoft Employee
2025-08-20T04:49:48.9233333+00:00

All instances are healthy, and diagnostic does not find anything wrong.

Azure Virtual Machine Scale Sets
Azure Virtual Machine Scale Sets
Azure compute resources that are used to create and manage groups of heterogeneous load-balanced virtual machines.
{count} votes

2 answers

Sort by: Most helpful
  1. Matteo Interlandi 25 Reputation points Microsoft Employee
    2025-08-22T17:52:41.59+00:00

    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

    1 person found this answer helpful.
    0 comments No comments

  2. Michele Ariis 6,255 Reputation points MVP
    2025-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.


Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.