SSH File Transfer Protocol (SFTP) support for Azure Blob Storage
Blob storage now supports the SSH File Transfer Protocol (SFTP). This support lets you securely connect to Blob Storage via an SFTP endpoint, allowing you to use SFTP for file access, file transfer, and file management.
SFTP support for Azure Blob Storage is not yet generally available in the West Europe region.
Here's a video that tells you more about it.
Azure allows secure data transfer to Blob Storage accounts using Azure Blob service REST API, Azure SDKs, and tools such as AzCopy. However, legacy workloads often use traditional file transfer protocols such as SFTP. You could update custom applications to use the REST API and Azure SDKs, but only by making significant code changes.
Prior to the release of this feature, if you wanted to use SFTP to transfer data to Azure Blob Storage you would have to either purchase a third party product or orchestrate your own solution. For custom solutions, you would have to create virtual machines (VMs) in Azure to host an SFTP server, and then update, patch, manage, scale, and maintain a complex architecture.
Now, with SFTP support for Azure Blob Storage, you can enable an SFTP endpoint for Blob Storage accounts with a single click. Then you can set up local user identities for authentication to connect to your storage account with SFTP via port 22.
This article describes SFTP support for Azure Blob Storage. To learn how to enable SFTP for your storage account, see Connect to Azure Blob Storage by using the SSH File Transfer Protocol (SFTP).
SFTP is a platform level service, so port 22 will be open even if the account option is disabled. If SFTP access is not configured then all requests will receive a disconnect from the service.
SFTP and the hierarchical namespace
SFTP support requires hierarchical namespace to be enabled. Hierarchical namespace organizes objects (files) into a hierarchy of directories and subdirectories in the same way that the file system on your computer is organized. The hierarchical namespace scales linearly and doesn't degrade data capacity or performance.
Different protocols are supported by the hierarchical namespace. SFTP is one of these available protocols. The following image shows storage access via multiple protocols and REST APIs. For easier reading, this image uses the term Gen2 REST to refer to the Azure Data Lake Storage Gen2 REST API.
SFTP permission model
Azure Blob Storage doesn't support Azure Active Directory (Azure AD) authentication or authorization via SFTP. Instead, SFTP utilizes a new form of identity management called local users.
Local users must use either a password or a Secure Shell (SSH) private key credential for authentication. You can have a maximum of 1000 local users for a storage account.
To set up access permissions, you'll create a local user, and choose authentication methods. Then, for each container in your account, you can specify the level of access you want to give that user.
Local users do not interoperate with other Azure Storage permission models such as RBAC (role based access control), ABAC (attribute based access control), and ACLs (access control lists).
For example, Jeff has read only permission (can be controlled via RBAC, ABAC, or ACLs) via their Azure AD identity for file foo.txt stored in container con1. If Jeff is accessing the storage account via NFS (when not mounted as root/superuser), Blob REST, or Data Lake Storage Gen2 REST, these permissions will be enforced. However, if Jeff also has a local user identity with delete permission for data in container con1, they can delete foo.txt via SFTP using the local user identity.
For SFTP enabled storage accounts, you can use the full breadth of Azure Blob Storage security settings, to authenticate and authorize users accessing Blob Storage via Azure portal, Azure CLI, Azure PowerShell commands, AzCopy, as well as Azure SDKs, and Azure REST APIs. To learn more, see Access control model in Azure Data Lake Storage Gen2.
You can authenticate local users connecting via SFTP by using a password or a Secure Shell (SSH) public-private keypair. You can configure both forms of authentication and let connecting local users choose which one to use. However, multifactor authentication, whereby both a valid password and a valid public-private key pair are required for successful authentication isn't supported.
You can't set custom passwords, rather Azure generates one for you. If you choose password authentication, then your password will be provided after you finish configuring a local user. Make sure to copy that password and save it in a location where you can find it later. You won't be able to retrieve that password from Azure again. If you lose the password, you'll have to generate a new one. For security reasons, you can't set the password yourself.
SSH key pairs
A public-private key pair is the most common form of authentication for Secure Shell (SSH). The private key is secret and should be known only to the local user. The public key is stored in Azure. When an SSH client connects to the storage account using a local user identity, it sends a message with the private key and signature. Azure validates the message and checks that the user and key are recognized by the storage account. To learn more, see Overview of SSH and keys.
If you choose to authenticate with private-public key pair, you can either generate one, use one already stored in Azure, or provide Azure the public key of an existing public-private key pair.
In the current release, you can specify only container-level permissions. Directory-level permissions aren't supported. You can choose which containers you want to grant access to and what level of access you want to provide (Read, Write, List, Delete, and Create). Those permissions apply to all directories and subdirectories in the container. You can grant each local user access to as many as 100 containers. Container permissions can also be updated after creating a local user. The following table describes each permission in more detail.
When performing write operations on blobs in sub directories, Read permission is required to open the directory and access blob properties.
As you configure permissions, you have the option of setting a home directory for the local user. If no other container is specified in an SFTP connection request, then the home directory is the directory that the user connects to by default. For example, consider the following request made by using Open SSH. This request doesn't specify a container or directory name as part of the
sftp firstname.lastname@example.org put logfile.txt
If you set the home directory of a user to
mycontainer/mydirectory, then they would connect to that directory. Then, the
logfile.txt file would be uploaded to
mycontainer/mydirectory. If you didn't set the home directory, then the connection attempt would fail. Instead, connecting users would have to specify a container along with the request and then use SFTP commands to navigate to the target directory before uploading a file. The following example shows this:
sftp email@example.com cd mydirectory put logfile.txt
Home directory is only the initial directory that the connecting local user is placed in. Local users can navigate to any other path in the container they are connected to if they have the appropriate container permissions.
You can use many different SFTP clients to securely connect and then transfer files. Connecting clients must use algorithms specified in table below.
|Host key 1||Key exchange||Ciphers/encryption||Integrity/MAC||Public key|
|rsa-sha2-256 firstname.lastname@example.org||hmac-sha2-256||ssh-rsa 2|
1 Host keys are published here. 2 RSA keys must be minimum 2048 bits in length.
SFTP support for Azure Blob Storage currently limits its cryptographic algorithm support based on security considerations. We strongly recommend that customers utilize Microsoft Security Development Lifecycle (SDL) approved algorithms to securely access their data.
At this time, in accordance with the Microsoft Security SDL, we don't plan on supporting the following:
hmac-sha1-96. Algorithm support is subject to change in the future.
Connecting with SFTP
To get started, enable SFTP support, create a local user, and assign permissions for that local user. Then, you can use any SFTP client to securely connect and then transfer files. For step-by-step guidance, see Connect to Azure Blob Storage by using the SSH File Transfer Protocol (SFTP).
Known supported clients
The following clients have compatible algorithm support with SFTP for Azure Blob Storage. See Limitations and known issues with SSH File Transfer Protocol (SFTP) support for Azure Blob Storage if you're having trouble connecting.
- AsyncSSH 2.1.0+
- Cyberduck 7.8.2+
- edtFTPjPRO 7.0.0+
- FileZilla 3.53.0+
- libssh 0.9.5+
- Maverick Legacy 1.7.15+
- Moveit 12.7
- OpenSSH 7.4+
- paramiko 2.8.1+
- PuTTY 0.74+
- QualysML 184.108.40.206+
- RebexSSH 5.0.7119.0+
- ssh2js 0.1.20+
- sshj 0.27.0+
- SSH.NET 2020.0.0+
- WinSCP 5.10+
- JSCH 0.1.54+
The supported client list above isn't exhaustive and may change over time.
Limitations and known issues
See the limitations and known issues article for a complete list of limitations and issues with SFTP support for Azure Blob Storage.
Pricing and billing
Enabling the SFTP endpoint has an hourly cost. We will start applying this hourly cost on or after January 1, 2023. For the latest pricing information, see Azure Blob Storage pricing.
Transaction, storage, and networking prices for the underlying storage account apply. To learn more, see Understand the full billing model for Azure Blob Storage.
- Connect to Azure Blob Storage by using the SSH File Transfer Protocol (SFTP)
- Limitations and known issues with SSH File Transfer Protocol (SFTP) support for Azure Blob Storage
- Host keys for SSH File Transfer Protocol (SFTP) support for Azure Blob Storage
- SSH File Transfer Protocol (SFTP) performance considerations in Azure Blob storage
Submit and view feedback for