Troubleshooting connectivity to Azure Storage over SFTP via Windows or Linux machine

Azure Storage supports for Secure File Transfer (SFTP) protocol in Azure Storage Account. We can use a SFTP client to securely connect to the Blob Storage endpoint of your Azure Storage account, and then perform upload and download operations over the account. Please note that SFTP feature support is only available for hierarchical namespace (ADLS Gen2) enabled accounts.

In this article, we will discuss about how to troubleshoot and isolate connectivity issues to SFTP storage account from your machine to understand whether this is due to port blockage, firewall issues, connectivity using private endpoint, incompatibility of the client being used due to unsupported algorithms whether from Windows or Linux machine. 

Let’s look at some of the steps/actions, you can perform from your side for isolation:

 

From Windows Machine

For Windows machines, we can make use of PowerShell or OpenSSH or WinSCP to connect to storage account via SFTP. In the below demo, we have used the authentication mechanism as SSH Key. For authentication mechanisms supported for SFTP, you can refer to the link: Connect to Azure Blob Storage using SFTP - Azure Storage | Microsoft Learn

 

Scenario 1: Verifying the connectivity to Port 22

SFTP requires that the outgoing connections via Port 22 to be allowed. You can check if port 22 is open or not by making use of the below command in Windows machine using PowerShell console.

Test-NetConnection -Port 22 -InformationLevel "Detailed"

Considering if the port 22 is blocked, you will get connectivity issues. In the below scenario we got “connection reset” error message.

Scenario 2: Storage account has firewall or VNET restrictions enabled.

If the storage account is behind firewall or VNet and you are trying to connect to storage account over SFTP, then there will be failure in connection to the storage account. You can refer to the below screenshot:

You can check this failed request ID in the Diagnostic Logging which will be pointing to IPAuthorizationFailure. As a mitigation, please ensure that the connection to the storage account and the VM from where you are accessing the storage account, is allowed in the storage account firewall rules.

 

Scenario3: Connectivity over Private Endpoint

If you have the storage account behind a private endpoint, please ensure that you are using the correct endpoint to connect. The connection will be made using the connection string as below:

[email protected]

If home directory hasn't been specified for the user, the connection string is defined as

myaccount.mycontainer.myuser@myaccount.privatelink.blob.core.windows.net.

To verify there is a connectivity between the storage account and the VM, you can also perform “nslookup” on the storage account endpoint. We should see the private IP of the storage account as a result of the resolution happening. If you observe a public IP in the response, it means that the connection is not happening via private endpoint of the storage account.

 

If the resolution is intact, you should be able to connect to SFTP successfully.

 

Scenario 4: Un-supported client due to incompatible algorithms.

In case you have validated port blockers, firewall and VNET configurations, and still facing connectivity issue with your SFTP client it is highly possible that the client might not be passing supported algorithms. You can use any SFTP client, however it must use the algorithm being discussed in the below link:

https://learn.microsoft.com/en-us/azure/storage/blobs/secure-file-transfer-protocol-support#supported-algorithms

 

If we try to connect using an unsupported algorithm, its connection will tend to fail. Below is a demonstration of an incorrect algorithm being passed resulting in connection failure.

 

If you are aware of the algorithm the client uses underneath, you can verify them again the above shared document. If not, you can take a network packet capture and check for the algorithms that are being passed during the negotiation.

 

You can check for the algorithms being passed between client to server and then service to client.

 

From Linux Machine

The above section talked about executing commands from Windows machine for isolation. In case you are using any Linux machine/client, you can do the isolation for that well. For this blog, we have made use of Linux Distribution of RHEL 8.6.

 

We will demonstrate connecting to Azure Storage Account using SFTP commands via OpenSSH or curl commands from Linux machine and check for isolation. 

 

Before proceeding with the commands, we need to test the connectivity to port 22 for which we can use Telnet command. We can telnet to the storage endpoint over the port 22.

 

Scenario 1: Verifying the connectivity to Port 22

Command to be used: 

 

 

telnet <host_storage_account_name> <port_number>

 

 

 

Scenario 2. Connect to the Storage Account using OpenSSH commands:

You can also make use of the curl command to upload to the Azure Storage Account from Linux.  We need to follow the below command for the upload operation.

 

 

curl -T <filename> -u <account>.<user>:<password> sftp:/<account>.blob.core.windows.net/~/<filename>

 

 

 

Here, parameter “T” stands for the file path on your local machine that you want to upload to the storage account. Adding the correct parameter, the above commands become as:

 

 

curl -T /home/shxxx/sample.yaml -u "<Account Name>.<Local User Name>:<SSH-Key> " -k "sftp:/<Account Name>.blob.core.windows.net/~/sample.yaml"

 

 

 

 

At present, SFTP feature has certain limitations for the Azure Storage Account. For more details on SFTP feature and its limitations on the storage account, you can refer to the below links:

• SFTP support for Azure Blob Storage - Azure Storage | Microsoft Learn
• Limitations & known issues with SFTP in Azure Blob Storage - Azure Storage | Microsoft Learn

Hope the article was helpful and do share your views on the same! If you have reviewed these checks but still facing connectivity issues, you can reach out to Microsoft Support ahead.