I keep getting disconnected from my linux vm instance in a vmss when using Azure Bastion to ssh into the host.

Question

While running commands on the vm such as systemctl status; cat on a file in the /etc/ root level directory while in su mode I keep getting kicked out of the vm and asking to reconnect when using the bastion premium tier. The exact steps to reproduce would be

use azure bastion to log into the vm via a ssh-key pulled from a keyvault.

once in the system run a sudo su

do a systemctl on a service you expect to be running on this vm

and at this step i get kicked out and asked to reconnect.

this vm sits in the same which has a nat in front of it to allow egress. The main function of this vmss is its setup as internal gitlab-runners to build/deploy applications.

Edit: I am not even able to run basic commands such as tail or check status of ssh.d

specs of vmss:

sku                 = "Standard_D4s_v3"

ip_configuration {
  name      = "internal"
  primary   = true
 moved to private
  version   = "IPv4"
}

Answer 1

switched to ssh via tunneling. https://learn.microsoft.com/en-us/azure/bastion/connect-vm-native-client-windows#connect-linux

Answer 2

Hello @rishbh rana    

The repeated SSH disconnects you’re seeing when using Azure Bastion (Premium) to access the Linux VMSS. Below are the concrete steps to stabilize sessions and verify networking:

1. Validate Bastion/VM NSG rules (both subnets) – Bastion subnet needs inbound/outbound rules as per Azure guidance; VMSS subnet must allow inbound TCP/22 from the Bastion subnet.
2. Avoid custom routes on Bastion; confirm reply path – Don’t attach UDRs to the Bastion subnet; ensure VM replies to Bastion over private IP (not via NAT/NVA).
3. If using Entra (AAD) SSH – Assign Virtual Machine Administrator Login/User Login appropriately may fail without the right RBAC.
4. Use Serial Console to isolate OS vs Bastion – Run the same commands from Serial Console to confirm no OS‑side drops.
5. Health & Auto‑shutdown – Verify Resource health is Healthy and Auto‑shutdown is off.
6. NAT Gateway – Keep it for internet egress; it should not alter intra‑VNet Bastion↔VM traffic.
7. Monitor sessions/metrics during the test window – Use Bastion Sessions and Azure Monitor to observe stability as you run Sudo/systemctl.

Expected result: With NSG/route cleanup and keepalives, SSH sessions should remain active during administrative operations. If any disconnects persist, we’ll use Serial Console evidence and Bastion session metrics to pinpoint whether the drops are client, Bastion, or OS‑side.

References:
https://learn.microsoft.com/en-us/azure/bastion/bastion-nsg
https://learn.microsoft.com/en-us/troubleshoot/azure/virtual-machines/linux/troubleshoot-ssh-connec…  

Thanks,
Manish Deshpande