Understanding WinError 10060
The error WinError 10060: A connection attempt failed because the connected party did not properly respond after a period of time is a standard Windows socket error. In the context of Azure Virtual Machines (VMs), this rarely means the code is syntactically wrong. Instead, it signifies that packets sent from your VM to the destination SFTP server are being dropped silently. This silence occurs because a firewall, network security group, or intermediate router has no rule permitting the traffic on the specific port used.
SFTP typically operates over port 22. If your Azure VM cannot reach an external SFTP endpoint, the most likely culprit is the outbound rule in the associated Network Security Group (NSG). By default, Azure allows outbound internet traffic, but custom rules or restrictive policies can block specific ports or IP ranges. Additionally, if you are connecting to an internal Azure service rather than the public internet, routing and peering settings may interfere.
Verifying Network Security Group Rules
The first step in troubleshooting is to inspect the NSG attached to your Azure VM’s network interface or subnet. You must ensure that an outbound rule exists allowing TCP traffic on port 22. If the rule is missing, you will need to add it. Navigate to the Azure Portal, select your VM, and click on Networking. Here you will see the list of applied NSGs.
- Check Outbound Rules: Look for a rule with priority lower than any deny-all rules. The source should be Any, the destination Any (or the specific IP range of the SFTP server), and the service port TCP 22.
- Priority Order: NSG rules are evaluated by priority number. Lower numbers take precedence. Ensure your allow rule has a lower number than any conflicting deny rule.
- Test Connectivity: After adding the rule, wait a few minutes for propagation. Then, try pinging the destination or using PowerShell to test the port:
Test-NetConnection -ComputerName sftp.example.com -Port 22. A successful test returnsTcpTestSucceeded : True.
If you are managing multiple VMs, consider applying these rules at the subnet level to maintain consistency. For more details on managing connectivity, you might find our article on Connecting Internet to VM helpful for broader network diagnostics.
Checking Python Script Configuration
Once network paths are confirmed, verify that your Python script is correctly configured. Common mistakes include using the wrong library, specifying the wrong port, or failing to handle SSH host key verification. If you are using the paramiko library, ensure you are instantiating the client correctly.
import paramiko
ssh = paramiko.SSHClient()
ssh.set_missing_host_key_policy(paramiko.AutoAddPolicy()) # Use with caution in production
ssh.connect(hostname='sftp.example.com', port=22, username='user', password='pass')
Notice the explicit definition of the port parameter. While 22 is the default, some servers use non-standard ports. If the server uses a different port, you must update the connection string accordingly. Also, ensure that your Azure VM’s system clock is synchronized. SSL/TLS handshakes and SSH negotiations can fail if there is a significant time drift between the client and server.
Handling Proxy Interferences
In enterprise environments, Azure VMs often route internet traffic through a corporate proxy. If your Python script does not account for this, it will hang until it times out with WinError 10060. If your environment requires a proxy, you must configure your HTTP/HTTPS libraries to use it. However, note that standard SFTP via paramiko does not automatically respect system proxy settings. You may need to use a SOCKS proxy wrapper or configure the underlying socket to tunnel through the proxy.
If you are using requests for other parts of your application, you can set proxies via environment variables or directly in the session object. But for SFTP, you generally need to bypass the proxy unless the proxy explicitly supports SOCKS5 tunneling for SSH traffic. Always check with your network administrator whether direct outbound access to port 22 is permitted or if it must go through a specific gateway.
Debugging with Wireshark or Azure Diagnostics
If the above steps do not resolve the issue, you may need deeper packet inspection. Install Wireshark on the Azure VM and capture traffic while running the Python script. Filter for the destination IP and look for SYN packets. If you see SYN packets leaving the VM but no SYN-ACK returning, the drop is happening at the network layer (Azure NSG or ISP firewall). If you see SYN-ACK but no subsequent handshake completion, the issue is likely at the application layer or due to stateful firewall restrictions.
Azure also provides flow logs for NSGs. Enable these logs in the Azure Portal under the NSG settings. They provide a detailed record of allowed and denied traffic flows, helping you pinpoint exactly which rule is blocking your connection. This diagnostic data is invaluable when dealing with complex multi-tier architectures.
Frequently Asked Questions
Why does ping work but SFTP fails?
Ping uses ICMP protocol, while SFTP uses TCP on port 22. Azure NSGs can allow ICMP traffic while blocking TCP port 22 specifically. Therefore, a successful ping does not guarantee that SFTP connectivity is open. You must explicitly test the TCP port using tools like Test-NetConnection or telnet.
Can I use FTP instead of SFTP to avoid this error?
Switching to FTP (port 21) might work if port 22 is blocked but port 21 is open, but this is highly discouraged. FTP transmits credentials in plain text, creating a severe security risk. SFTP is encrypted and should be preferred. If port 22 is blocked, fix the NSG rule rather than downgrading to insecure protocols.
How do I update Python if I installed it via Microsoft Store?
If you suspect your Python version is outdated and causing compatibility issues, you can update it without reinstalling. See our guide on Updating Python 3 Installed Through the Microsoft Store Without Reinstalling a New Version to ensure you have the latest patches and library support.
What if the SFTP server is inside another Azure VNet?
If the target is internal, you must ensure VNet peering is established and working. Additionally, check the NSG rules on both the source and destination VNets. Peering alone does not bypass NSG filtering; both sides must allow the traffic. Verify that private IP addresses are reachable and that no route tables are directing traffic unexpectedly.
Does Azure Firewall block SFTP by default?
Azure Firewall policies can be configured to deny all outbound traffic except for specific FQDNs or IPs. If your organization uses Azure Firewall, ensure that the SFTP server’s domain or IP is added to the allowed list. Unlike NSGs, Firewall policies require explicit FQDN tags or URL filters depending on the configuration mode.