Azure SFTP Connection Disconnects on Port 22 from Linux VM

Jayraj Singh 0 Reputation points
2026-08-13T13:32:10.3433333+00:00

I have a window vm in that i have a another hyper v window-A vm and another linux vm whole connectivity is completely private when i try to connect sftp server i got Disconnected from port 22 error while i am able to reach the my storage privateEndpoint but when i tried to transfer the file from window-B vm which is another hyper v vm i was able to connect sftp server . this i a site-to-site setup . image (1)

Azure Data Lake Storage
Azure Data Lake Storage

An Azure service that provides an enterprise-wide hyper-scale repository for big data analytic workloads and is integrated with Azure Blob Storage.

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Marcin Policht 107.2K Reputation points MVP Volunteer Moderator
    2026-08-13T13:47:04.1033333+00:00

    According to the screenshot, the Linux VM is successfully reaching the Azure Storage private endpoint at 10.6.0.5 on TCP/22. The failure occurs after the SSH/SFTP connection is established. The message “Received disconnect from 10.6.0.5 port 22” means the Storage SFTP service is actively closing the session, rather than TCP/22 simply being blocked.

    Because Window-B VM can successfully connect through the same site-to-site path, while the nested Linux VM cannot, I would focus on the difference in the source network path. The Linux VM is behind Hyper-V inside Window-A, so its traffic may be routed/NATed differently. In particular, verify whether Window-A is forwarding the Linux VM traffic correctly and what source IP the Azure side ultimately sees.

    From the Linux VM, run sftp -vvv ******@jayrajstorageacc.blob.core.windows.net and compare the output with a successful connection from Window-B. Also verify that the hostname resolves to 10.6.0.5 on both systems and test nc -vz jayrajstorageacc.blob.core.windows.net 22. If both resolve to 10.6.0.5 and TCP/22 succeeds, the next thing to investigate is SFTP authentication/session handling or the source IP/NAT behavior of the nested Hyper-V VM, not the site-to-site VPN itself.

    If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

    hth

    Marcin

    Was this answer helpful?

  2. AI answer

    2026-08-13T13:32:43.05+00:00

    The failure is most likely in the network path or SSH path from the Linux VM, not in the Storage SFTP endpoint itself, because the Windows-B VM can connect successfully.

    Use this troubleshooting path:

    1. Verify port 22 reachability from the Linux VM
      • From the Linux VM, confirm the destination is reachable on SSH port 22.
      • If the connection drops immediately after authentication starts, compare the path from Linux VM versus Windows-B VM.
    2. Check NSG rules on the Azure VM and subnet
      • In Azure portal, open the VM that hosts the traffic path.
      • Go to Networking.
      • Confirm there is no rule blocking TCP 22.
      • Review rule priority carefully. Lower numbers are matched first, so an earlier deny rule can override later allow rules.
      • Also verify the default rules such as Allow VNet Inbound and Allow Load Balancer Inbound where applicable.
    3. Check effective security rules
      • In the VM troubleshooting flow, review effective security rules to confirm an inbound Allow rule exists for SSH port 22 and that it has higher priority than any deny rule.
      • This is important in private and site-to-site topologies where subnet, NIC, or inherited rules can differ between VMs.
    4. Check routing
      • In Azure portal, go to the VM’s Networking settings.
      • Select the network interface, then Effective routes.
      • Look for a user-defined route sending traffic to an unexpected next hop, such as an NVA or firewall appliance.
      • In a site-to-site setup, asymmetric routing or a forced-tunnel route can cause disconnects from one VM while another VM still works.
    5. Check the Linux VM firewall and SSH client path
      • Temporarily disable the Linux VM firewall and test again.
      • If the connection works, re-enable the firewall and correct the rules.
      • Also verify the Linux VM can establish SSH traffic normally and that no local filtering is interfering.
    6. Check whether the SSH service is listening on the expected port when troubleshooting Linux-side SSH behavior
      • If the issue involves the Linux VM’s own SSH handling or a nested/private path, use: 
             sudo systemctl status sshd.service
     sudo ss --listen --tcp --process --numeric | grep sshd
      • This confirms whether SSH is active and which port is in use.
    7. Use Azure network diagnostics
      • Use IP flow verify to confirm whether an NSG rule is blocking traffic.
      • Use Next hop to confirm routing is correct.
      • These checks help isolate whether the disconnect is caused by security filtering or route redirection.
    8. Compare the working and failing VMs
      • Since Windows-B works and Linux VM fails, compare:
        • effective NSG rules
        • effective routes
        • local firewall behavior
        • whether both VMs use the same DNS resolution and same private endpoint path
        • whether one VM is behind a different NAT, appliance, or Hyper-V virtual switch path

    If the issue is only from the Linux VM and the Storage private endpoint is reachable, the most likely causes are:

    • an NSG or firewall rule affecting TCP 22
    • a route difference in the site-to-site path
    • local Linux-side filtering or SSH path differences

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

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.