after resizing a virtual machine I cannot connect via ssh

Question

after resizing a virtual machine I cannot connect via ssh

Tucker Thames 0

after resizing a virtual machine I cannot connect via ssh. I can connect via the serial console. I have tried a number of steps including redeploying and re-applying, reverting back to the old size, double checking nsg rules, opening up nsg rules temporarily to allow any source, creating a new key to ensure I am using a valid key pair, and more suggestions from co-pilot and gmeini. No matter what when I try to connect i get a Network Error: Connection timed out.

Has anyone had this issue?

Manish Deshpande 6,915 Reputation points Microsoft External Staff Moderator

2026-05-06T16:42:57.1266667+00:00
Hello @Tucker Thames

Please try this Quick troubleshooting steps

After each troubleshooting step, try reconnecting to the VM.

Reset the SSH configuration.

Reset the credentials for the user.

Verify the network security group rules permit SSH traffic and role assignment.

Ensure that a Network Security Group rule exists to permit SSH traffic (by default, TCP port 22).

You cannot use port redirection / mapping without using an Azure load balancer.

If you are using Microsoft Entra ID to manage SSH logins, the user must be assigned the Virtual Machine Administrator Login or Virtual Machine User Login role on the resource group that contains the VM and its associated resources. Otherwise, the "Permission denied (publickey)" error will be received. For more information, see Configure role assignments for the VM that uses Microsoft Entra login.

Check the VM resource health.

Ensure that the VM reports as being healthy.

If you have boot diagnostics enabled, verify the VM is not reporting boot errors in the logs.

Restart the VM.

Redeploy the VM.

Link : https://learn.microsoft.com/en-us/troubleshoot/azure/virtual-machines/linux/troubleshoot-ssh-connection#use-the-azure-vm-serial-console

If you encounter any errors please help us with the snip of the errors we will be happy to assist you.

Thanks,
Manish.
Tucker Thames 0 Reputation points

2026-05-08T15:07:39.0333333+00:00

Manish,

I have tired all the steps above again. This is the same steps that I tried before and the same steps that Copilot had me try.
Manish Deshpande 6,915 Reputation points Microsoft External Staff Moderator

2026-05-14T00:43:30.2466667+00:00

Hello @Tucker Thames

Pls provide your best time to connect with you over the teams call to fix the issue.
Manish Deshpande 6,915 Reputation points Microsoft External Staff Moderator

2026-05-21T17:42:33.0233333+00:00
Hello @Tucker Thames ,

Thank you for your patience, and I sincerely appreciate you walking through all of those steps thoroughly. I completely understand how frustrating it is to have exhausted the standard troubleshooting path and still be blocked especially when you can reach the VM via the Serial Console, which tells us the VM itself is healthy and running.

Since the Serial Console works but SSH is timing out across all attempts (even with open NSG rules), this strongly suggests the issue is rooted in the network layer specifically, the NIC or routing configuration may have been disrupted during the resize operation. Let's go deeper with the following targeted steps:

Summary of the Root Cause

When an Azure VM is resized, the underlying host changes. This can occasionally cause the Network Interface Card (NIC) configuration to become stale or misaligned, even though the VM and NSG appear healthy. The "Connection timed out" error (as opposed to "Connection refused") confirms that packets are not reaching the SSH daemon — pointing to a network-path issue, not an SSH service issue.

Step 1: Reset the NIC (Most Likely Fix)

This is the most targeted fix for post-resize SSH failures. Use the Azure CLI command:

az vm repair reset-nic --name <YourVMName> --resource-group <YourResourceGroup> --subscription <YourSubscriptionID>

Alternatively, via the Azure Portal:

Navigate to your VM → Networking → select the Network Interface.

Go to IP configurations → select the IP config.

Change Private IP assignment from Dynamic to Static, assign a different available IP in the subnet.

The VM will restart and reinitialize the NIC.

After reconnecting successfully, you may revert to Dynamic or your original IP.

Reference:
https://learn.microsoft.com/en-us/troubleshoot/azure/virtual-machines/linux/reset-network-interface-azure-linux-vm

Step 2: Use Network Watcher – IP Flow Verify

This tool will definitively tell you whether traffic on TCP port 22 is being allowed or denied at the NSG layer — and which specific rule is responsible:

In the Azure Portal, open Network Watcher.

Under Network diagnostic tools, select IP Flow Verify.

Set:

Virtual Machine: Your affected VM

Direction: Inbound

Protocol: TCP

Local port: 22

Remote IP: Your SSH client's public IP

Click Check.

If it says Allow but SSH still fails, the NSG is not the problem which brings us to Step 3.

Reference:
https://learn.microsoft.com/en-us/azure/network-watcher/ip-flow-verify-overview

Step 3: Use Network Watcher – Connection Troubleshoot

This provides an end-to-end path analysis (NSG + routing + reachability):

In Network Watcher, select Connection troubleshoot.

Source: Your VM | Destination: Your client IP | Port: 22 | Protocol: TCP.

Click Check and review the hops and any blocking rules identified.

Reference:
https://learn.microsoft.com/en-us/troubleshoot/azure/virtual-network/virtual-network-troubleshoot-connectivity-problem-between-vms

Step 4: Verify Effective Routes via Network Watcher – Next Hop

A VM resize can occasionally affect routing tables. Use Next Hop in Network Watcher to confirm that the route for your client IP is correctly pointed to the Internet gateway and not to a black hole:

In Network Watcher, select Next hop.

Select your VM and its NIC.

Enter your client's source IP as the destination.

Verify the next hop type is Internet.

Reference:
https://learn.microsoft.com/en-us/troubleshoot/azure/virtual-machines/linux/detailed-troubleshoot-ssh-connection

Step 5: Use the Serial Console to Verify SSH is Listening

Since you have Serial Console access, please run these commands directly to confirm SSH is active inside the VM:

sudo systemctl status sshd sudo ss -tlnp | grep 22

If SSH is running and listening on port 22, the issue is definitively outside the VM (network/NIC layer). If SSH is not running, start it with:

sudo systemctl start sshd sudo systemctl enable sshd

Reference:
https://learn.microsoft.com/en-us/troubleshoot/azure/virtual-machines/linux/troubleshoot-ssh-connection#use-the-azure-vm-serial-console

Takeaway

The fact that all standard steps including NSG open rules, credential reset, and redeployment — have not resolved this strongly points to a NIC-level issue introduced during the VM resize. The NIC reset (Step 1) is the most targeted and likely fix. Network Watcher tools (Steps 2–4) will provide definitive diagnostic evidence if the issue persists.

If the above steps do not resolve the issue, please do not hesitate to comment below with the output from the Serial Console commands and the Network Watcher results. We are happy to assist you further and will respond promptly.

Thanks,

Manish
Manish Deshpande 6,915 Reputation points Microsoft External Staff Moderator

2026-05-22T18:37:18.6533333+00:00

I wanted to check if my last response made sense. I’d be glad to assist further or explain anything in more detail and please accept as Yes and upvote if the answer is helpful so that it can help others in the community.

2 answers

Your answer

Manish Deshpande 6,915 Reputation points Microsoft External Staff Moderator

2026-05-06T16:42:57.1266667+00:00

Hello @Tucker Thames

Please try this Quick troubleshooting steps

After each troubleshooting step, try reconnecting to the VM.

Reset the SSH configuration.

Reset the credentials for the user.

Verify the network security group rules permit SSH traffic and role assignment.

Ensure that a Network Security Group rule exists to permit SSH traffic (by default, TCP port 22).

You cannot use port redirection / mapping without using an Azure load balancer.

If you are using Microsoft Entra ID to manage SSH logins, the user must be assigned the Virtual Machine Administrator Login or Virtual Machine User Login role on the resource group that contains the VM and its associated resources. Otherwise, the "Permission denied (publickey)" error will be received. For more information, see Configure role assignments for the VM that uses Microsoft Entra login.

Check the VM resource health.

Ensure that the VM reports as being healthy.

If you have boot diagnostics enabled, verify the VM is not reporting boot errors in the logs.

Restart the VM.

Redeploy the VM.

Link : https://learn.microsoft.com/en-us/troubleshoot/azure/virtual-machines/linux/troubleshoot-ssh-connection#use-the-azure-vm-serial-console

If you encounter any errors please help us with the snip of the errors we will be happy to assist you.

Thanks,
Manish.
Tucker Thames 0 Reputation points

2026-05-08T15:07:39.0333333+00:00

Manish,

I have tired all the steps above again. This is the same steps that I tried before and the same steps that Copilot had me try.
Manish Deshpande 6,915 Reputation points Microsoft External Staff Moderator

2026-05-14T00:43:30.2466667+00:00

Hello @Tucker Thames

Pls provide your best time to connect with you over the teams call to fix the issue.
Manish Deshpande 6,915 Reputation points Microsoft External Staff Moderator

2026-05-22T18:37:18.6533333+00:00

I wanted to check if my last response made sense. I’d be glad to assist further or explain anything in more detail and please accept as Yes and upvote if the answer is helpful so that it can help others in the community.

Answer 1

Hey Tucker, it’s great that you can still hit the serial console—that tells us your VM is up and SSHd is likely running, so a “Connection timed out” really points to something in the network path. Resizing sometimes leaves the NIC in a weird state. Here’s a targeted plan:

Reset the NIC • CLI: az vm repair reset-nic --resource-group <RG> --name <VMName> --subscription <SubID> • Portal:
- VM → Networking → select the NIC → IP configurations
- Switch Private IP from Dynamic to Static (choose a free IP)
- Let the VM restart, confirm SSH connectivity, then you can revert to Dynamic if you like
(This reinitializes the NIC on the new host.)
Run IP Flow Verify (Network Watcher) • Portal → Network Watcher → IP Flow Verify • VM: your Linux VM • Direction: Inbound, Protocol: TCP, Local port: 22, Remote IP: your client IP • This tells you if an NSG rule is blocking or allowing the traffic.
Run Connection Troubleshoot (Network Watcher) • Network Watcher → Connection troubleshoot • Source: your VM, Destination: your client IP, Port 22, Protocol TCP • You’ll get a hop-by-hop path analysis and see exactly where packets drop.
Check Effective Routes (Next Hop) • Network Watcher → Next hop • Select your VM’s NIC, enter your client IP as destination • Verify the next hop is “Internet” (or your expected gateway).
Confirm SSHd inside the VM From the serial console or Run Command: sudo systemctl status sshd sudo ss -tlnp | grep :22 If SSHd isn’t listening, start/enable it: sudo systemctl start sshd && sudo systemctl enable sshd

If after Step 1 SSH still times out but the NSG shows “Allow,” then we know it’s truly a NIC or routing issue. Please share the results from the IP Flow Verify and Connection Troubleshoot tools so we can pinpoint where it’s getting dropped.

Hope this helps get you back on SSH quickly!

Reference list

• Reset NIC on Linux VM after resize:

https://learn.microsoft.com/troubleshoot/azure/virtual-machines/linux/reset-network-interface-azure-linux-vm

• Quick SSH troubleshooting:

https://docs.microsoft.com/azure/virtual-machines/troubleshooting/troubleshoot-ssh-connection

• IP Flow Verify overview:

https://learn.microsoft.com/azure/network-watcher/ip-flow-verify-overview

• Connection troubleshoot (path analysis):

https://learn.microsoft.com/en-us/troubleshoot/azure/virtual-network/virtual-network-troubleshoot-connectivity-problem-between-vms

• Next hop (effective routes):

https://learn.microsoft.com/en-us/troubleshoot/azure/virtual-machines/linux/detailed-troubleshoot-ssh-connection

• Use the Azure VM serial console:

https://learn.microsoft.com/azure/virtual-machines/linux/serial-console#accessing-serial-console-for-linux

Note: This content was drafted with the help of an AI system. Please verify the information before relying on it for decision-making.

Answer 2

Resizing can expose or change underlying compute/network behavior, so focus on verifying that SSH is actually listening and reachable from inside the VM, then work outward.

Since Serial Console works, use it (or Run Command) to run these checks and fixes:

Confirm SSH service is running and listening In Serial Console:
```
   sudo systemctl status sshd.service
```
If it is not active (running), start/restart it:
```
   sudo systemctl restart sshd.service
```
Then verify it is listening on the expected port (usually 22):
```
   sudo ss --listen --tcp --process --numeric | grep sshd
```
Expected output should show something like:
```
   LISTEN 0 128 0.0.0.0:22 ...
   LISTEN 0 128 [::]:22   ...
```
If nothing is returned, SSH is not listening; reset the SSH configuration (step 3).
Confirm SSH port configuration Still in Serial Console, check /etc/ssh/sshd_config:
```
   grep -i port /etc/ssh/sshd_config
   grep -i listen /etc/ssh/sshd_config
```
If no non-comment Port line is present, default is port 22. If a different port is configured, ensure that is the port being used from the client and allowed in NSG.

Reset SSH configuration from Azure side If SSH is not running or appears misconfigured, reset it to defaults using Azure CLI:

   az vm user reset-ssh --resource-group <yourRG> --name <yourVM>

This resets SSH configuration without changing users or keys. If needed, also reset credentials/keys:

   az vm user update --resource-group <yourRG> --name <yourVM> \
       --username <user> --ssh-key-value "$(cat ~/.ssh/id_rsa.pub)"

Alternatively, use the VMAccess extension with a settings.json containing:

   { "reset_ssh": true }

and apply it:

   az vm extension set --resource-group <yourRG> --vm-name <yourVM> \
       --name VMAccessForLinux --publisher Microsoft.OSTCExtensions \
       --version 1.2 --settings settings.json

Verify NSG and networking again (post-resize) After confirming SSH is listening on the VM:
- Ensure the NIC/subnet NSG has an inbound rule allowing TCP 22 from the client IP.
- Confirm there is no higher-priority deny rule blocking it.
- If using a different SSH port, allow that port instead.
- Check that the VM still has the expected public IP and that any upstream firewall allows SSH.
Check VM health and restart/redeploy if needed
- In the portal, verify Resource health is healthy and boot diagnostics show no boot errors.
- If everything looks healthy but SSH still times out, restart the VM:
  - Portal: select the VM → Restart.
  - CLI:
```
       az vm restart --resource-group <yourRG> --name <yourVM>
```
- If the issue persists, redeploy the VM to a new node (noting ephemeral disk data loss and dynamic IP changes) using Redeploy in the portal or:
```
     az vm redeploy --resource-group <yourRG> --name <yourVM>
```
Use Run Command if Serial Console is limited If Serial Console is restricted (for example, key-only auth issues), use Run Command in the Azure portal to run the same systemctl, ss, and grep commands non-interactively and inspect output.

Following this sequence ensures SSH is running and listening inside the VM, correctly configured on the expected port, and reachable through Azure networking after the resize.

References:

Troubleshoot SSH connections to an Azure Linux VM that fails, errors out, or is refused

Share via

after resizing a virtual machine I cannot connect via ssh

2 answers

Your answer