You dont have javascript enabled! Please enable it!

How to Deploy a Secure FTP (SFTP) Service on Microsoft Azure

16 Min. Read

In this article, we will share with you how to deploy a secure (SFTP) service on Microsoft Azure and Azure File Shares.

Azure SFTP Updates

Based on the user’s feedback and comments, the SFTP deployment in Azure was updated with 8 new options as follows:

1) Updated – 12/05/2023 – See also how to deploy SFTP service on Microsoft Azure using Azure Container Apps (ACA) – New Solution.

2) Updated – 28/11/2021 – Azure now offers a fully-managed SFTP service built on top of Blob Storage that may be more suitable for your use case; look at the step-by-step guide to see if it meets your requirements.

3) Updated – 13/04/2021 – A new scenario was created to integrate the SFTP service with an existing Azure virtual network, so you can transfer files to SFTP over a private IP instead of pubic IP addresses. This scenario is useful if you have a site-to-site VPN between your on-premises network and Azure, or if you need an SFTP service within your Azure environment. In this case, you keep SFTP access private for added security. Please check the following section for more details on deploying that scenario.

4) Updated – 10/04/2021 A new scenario was created to address the most requested feature by the readers. Add multiple users for the SFTP and have multiple different file shares mounted for each user. Please check the following section for more details on deploying that scenario.

5) Updated – 01/02/2021 A new scenario was created to address and limit the access of who can upload files via SFTP. In this scenario, you will use the container to upload files via SFTP from specific public IPs only for added security, then you can access those files via a web service (HTTP/HTTPS) from anywhere. Please check the following section for more details on how to deploy that scenario.

6) Updated – 11/11/2020 A new scenario was created to address the authentication scenario using SSH keys instead of using usernames and passwords. Please check the following section for more details on how to deploy it.

7) Updated – 06/10/2020 – The ARM Template has been updated to include the new file share access tier to reduce cost, you can choose now between (Hot, Cool, or Transaction Optimized).How to Deploy a Secure FTP (SFTP) Service on Microsoft Azure 1

8) Updated – 05/10/2020 – The ARM Template has been updated to mount the volume inside the container instance with the same Azure file share name. This is useful if you want to create another folder with a certain name that you need for a specific project.

How to Deploy a Secure FTP (SFTP) Service on Microsoft Azure 2

What would you like to see next? You are welcome to share your thoughts in the comment section below.

Introduction

SSH File Transfer Protocol (SFTP) is a network protocol used for secure file transfer over a secure shell. FTP/SFTP is still a very common protocol used by many customers in several industries. Microsoft does not have a fully managed SFTP service in Azure yet, however, Amazon AWS has an SFTP as a service, and if you are purely an Azure customer, then this is a less desirable solution.

Updated – 17/11/2021 – After more than two years of waiting, Microsoft finally released a fully managed SFTP (PaaS) service based on Microsoft Azure Blob Storage.

So, if you still want to deploy a secure and flexible SFTP on Azure today, you still have a couple of options as follows:

1) Get a FileZilla Pro license and send the files to Azure blob storage, however, this is still an IaaS solution and not a full PaaS solution.

2) Use a third-party solution such as SFTP on Files.com and integrate with Microsoft Azure blob storage. Files.com is a great solution that integrates seamlessly with Azure. Check the following step-by-step guide and see how to mount Azure blob storage on top of the FTP/SFTP service.

3) Use an Azure Container Instance (ACI) powered by an Azure File Share as a storage back-end for a less VM approach (the topic of this article). This solution will be a good workaround for a cost-effective SFTP solution in Azure which is backed by durable persistent storage. ACI service is inexpensive and requires very little maintenance, while data is stored in Azure Files which is a fully managed SMB service in the cloud.

4) Or, use Azure Blob storage instead of Azure Container Instance (ACI) and Azure Files. Check the following article on how to enable SFTP support for Azure Storage step-by-step.

In this article, we will share with you how to deploy an SFTP service based on Azure Container Instance (ACI) and Azure File Shares.

Deploy SFTP Service on Azure

Microsoft has released two Azure ARM Templates to create an on-demand SFTP Service on Azure for two different scenarios:

1) Scenario 1: Create an SFTP Service with a new Azure file share. Please note that this template from Microsoft is out of support now, please refer to my updated templates below.

2) Scenario 2: Create SFTP Service with an existing Azure file share. Please note that this template from Microsoft is out of support now, please refer to my updated templates below.

This template creates an on-demand SFTP server using an Azure Container Instance (ACI). It creates a Storage Account and a File Share via the Azure CLI using another ACI. This File Share is then mounted into the main ACI to provide persistent storage after the container is terminated. The container is Linux-based. The beauty of this solution is, that once your transfer/upload is completed, you can stop the ACI and the files will remain accessible. You can also delete/recreate the ACI and mount the same file share to copy more files.

Updated Azure SFTP Templates

Please note that the templates published by Microsoft above are out of support now, they used an old Azure-CLI image and it creates a (general purpose v1) storage account. To this end, I have updated the ARM template to support (general purpose v2) storage account type besides the improvement mentioned in the updates section. Additionally, the price per GB for general-purpose v1 and general-purpose v2 storage accounts is the same. So why not use the latest Azure storage features?

Click on the “Deploy to Azure” button and follow the steps as shown in the video below to deploy an SFTP service with a new Azure storage account and file share (Scenario 1).

Deploy To Azure

Please take note of the username and password during the deployment since you will need to use them to access the SFTP service in the next step.

Last but not least, copy the public IP address from the container group (sftp-group), and then connect securely to the SFTP service with your desired FTP client such as (FileZilla).

Enjoy :)

Restrict Public IP Access

Now the SFTP service is publicly accessible from anywhere over a secure shell. You have a new requirement to whitelist specific IPs to connect to the SFTP service. In other words, you want to restrict access to the SFTP service in Azure and allow only a certain set of IP ranges.

What you could do is the following, you can implement a Network Security Group (NSG) on the subnet in Azure and then only allow Inbound communications from specific public IP ranges. Now to use an NSG, you’ll need to deploy the Azure Container Instances (ACI) into a virtual network (VNET) as documented by Microsoft here.

However, as noted in the “limitations” section there, Public IP isn’t supported in this scenario (Container groups deployed to a virtual network don’t currently support exposing containers directly to the internet with a public IP address or a fully qualified domain name), so you would need to proxy the connection through something else that would support the IP restrictions such as using an Azure Firewall for example. Hopefully, the Azure Container Team will address that limitation soon.

To restrict access to the SFTP service, please check the following section where you can enable an IP allowlist and co-locate Nginx as the front-end with SFTP in the backend.

Restricted SFTP access with NGINX Reverse Proxy

NGINX is one of the most popular web servers in the world. Not only is NGINX a fast and reliable static web server, but it is also used by a ton of developers as a reverse proxy that sits in front of their APIs.

A reverse proxy server is a server that typically sits in front of other web servers to provide additional functionality that the web servers may not provide themselves.

For example, a reverse proxy can provide SSL termination, load balancing, request routing, caching, compression, or even A/B testing.

When running web and SFTP services in docker containers, it can be useful to run a reverse proxy in front of the containers so you can have more control over who can access your files and serve static content using Nginx for example.

In this section, I will share with you a useful and interesting scenario where you can use the container with SFTP to upload files from a restricted set of public IP addresses, and then use Nginx reverse proxy as a front-end to access those files securely via HTTPS.

The entire process is the following:

1) Update the following Nginx.conf file with your public IP addresses that you want to allow who can upload files via SFTP. In this configuration, I have two ports so we can connect via SFTP to the public IP using port 2222 (which is passed to port 22 of the SFTP container) and also connect natively to port 80 with HTTP.

user  nginx;
worker_processes  1;

error_log  /var/log/nginx/error.log warn;
pid        /var/run/nginx.pid;

events {
    worker_connections  1024;
}

http {
    default_type  application/octet-stream;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;

    sendfile        on;
    #tcp_nopush     on;

    keepalive_timeout  65;

    #gzip  on;

    include /etc/nginx/conf.d/*.conf;

    server {
        root /mnt/sftp;
        listen 80;
        location / {
            autoindex on;
        }
    }
}

stream {
    server {
        listen 2222;
        proxy_pass localhost:22;
        allow add_your_public_ip_1;
        allow add_your_public_ip_2;
        allow add_your_public_ip_3;
        # Need this IP range for the ACI monitoring infrastructure
        allow 10.240.0.0/16;
        deny all;
    }
}

2) Upload the updated Nginx.conf file to an existing Azure file share, assuming you already have a storage account deployed in Microsoft Azure. In this way, Nginx will be configured at runtime automatically.

3) Deploy the SFTP service using the ARM template (more on this in a bit).

4) Connect using the public IP address or the container DNS (FQDN) via TCP Port 2222, then authenticate to the SFTP service using your favorite FTP/SFTP client (FileZilla), and upload some files.

5) Access the SFTP Service using the public IP address or the container DNS (FQDN) from your favorite browser and enjoy!

Click on the “Deploy to Azure” button and follow the steps as shown in the video below to deploy the SFTP service with a username and password authentication (for SSH keys authentication, check the next deployment option). The template will create a new Azure storage account and one file share, assuming that you have already uploaded the Nginx.conf file to an existing Azure storage account and file share.

Deploy To Azure

For SSH keys authentication, click on the “Deploy to Azure” button below to deploy the SFTP service with Nginx reverse proxy. The template will create a new Azure storage account and one file share, assuming that you have already uploaded the Nginx.conf file to an existing Azure storage account and file share.

Deploy To Azure

With this scenario, you will use the container for SFTP to upload files from restricted public IP addresses, then you can access those files as static via HTTP/HTTPS using Nginx reverse proxy as the front-end.

Logging in with SSH keys

If you interact regularly with SSH commands and remote hosts, you may find that using a key pair instead of passwords can be convenient. Instead of the remote system prompting for a password with each connection, authentication can be automatically negotiated using public and private key pairs.

In this section, I will share with you another interesting scenario that you can use to log in and authenticate with SSH keys to your SFTP service based on Azure Container Instance (ACI) instead of using passwords.

The entire process is the following:

1) Generate your SSH (public/private) keys with OpenSSH: ssh-keygen -t rsa -b 4096 -f ssh_sftp_rsa_key

2) Deploy the SFTP service using the new ARM template (more on this in a bit).

3) Upload your public key (xxxxx.pub) to the Azure File Share where the SSH key will be stored (e.g. adminsftp).

4) Restart the Azure Container Instance (sftp-group).

5) Load the private key on your machine using (Pageant from PuTTY) for example.

6) Connect using the public IP address and authenticate to the SFTP service using your favorite FTP/SFTP client (FileZilla) for example.

Click on the “Deploy to Azure” button and follow the steps as shown in the video below to deploy the SFTP service with a new storage account and two Azure file shares, one for the SFTP data upload, and the second one will be used to store the SSH public keys.

Deploy To Azure

Add multiple users for SFTP in Azure

In this section, I will show you how to add multiple users for the SFTP so you can have multiple different shares mounted for each user by using public SSH keys authentication instead of using Passwords.

We have two different possibilities:

1) The first one is to create one user per file share and then mount each user to the corresponding file share (1:1 mapping). In this option, we can use the same Azure Container Instance (ACI) – one container only.

2) An alternative option would be to have a different Azure Container Instance (ACI) per user, however, this option will cost more money, and you want to make sure that you shut down the container instances when they weren’t in use to minimize the cost.

Please note that I won’t cover scenario 2 here to make sure we have an affordable SFTP solution in Azure.

Now the Pros and Cons for each option noted above:

1) For the first one, you need to update the ARM template manually if you want more than three users, then adjust the Environment Variables, and finally update the volume mounts section in the container to match the number of users, so this option is a more static approach. In this example, I will create three users, three Azure file shares for upload, and additional three file shares for SSH keys (one per user), so the other user does not see the other public keys in the .ssh/keys folder (secure by design). Please note that the creation of Azure file shares (upload folder and SSH keys folder) is dynamic so you don’t want to adjust this in the template.

2) However, with option two, we can leverage the dynamic capability of the copy element in the ARM template, and create dynamically the number of users that we want with multiple Azure Container Instances (one ACI per user).

The entire process for the deployment is the following:

1) Generate your SSH (public/private) keys with OpenSSH for each user by using the following command: ssh-keygen -t rsa -b 4096 -f ssh_sftp_rsa_key

2) Deploy the SFTP service using the new ARM template (more on this in a bit).

3) Upload your public key (xxxxx.pub) to the Azure File Share where the SSH key will be stored for each user (e.g. sshkey-username) file share.

4) Restart the Azure Container Instance (sftp-group).

5) Load the private key on your machine using (Pageant from PuTTY) for example.

6) Finally, connect using the public IP address and authenticate to the SFTP service using your favorite FTP/SFTP client.

Click on the “Deploy to Azure” button and follow the steps as shown in the video below to deploy the SFTP service with multiple users and multiple shares mounted for each user. In this example, I will be using SSH key authentication instead of passwords.

Deploy To Azure

Please remember that if you change the number of users, the deployment will take only the first three users. You need to update the environment variables section, as well as, the volume mounts.

What about creating multiple users for one Azure File Share?

This is unfortunately quite a complex task, as the default behavior of the SFTP container is to force a separate folder for each user.

To get around this, you would need to create a new container image based on the existing one, and modify a few things:

  • sshd_config to change the ChrootDirectory to one of your choice rather than %h (i.e. each user home).
  • create-sftp-user script to create the directory of your choice and then ensure the correct permissions are set.
  • Change the ARM template to mount the Azure File share to this new directory.

That’s it there you have it!

SFTP access over Private IP in Azure

In this section, I will show you how to deploy the SFTP service in Azure and integrate it with your existing virtual network.

The entire process for the deployment is the following:

1) Deploy the SFTP service using the new ARM template (more on this in a bit).

2) Specify your existing virtual network name.

3) Specify your existing resource group name where the virtual network is created.

4) Enter a new subnet name and address prefix in CIDR format (i.e. 10.71.11.0/24). In this step, I create a new subnet dedicated to the Azure Container Instances, because Azure delegates the subnet to Azure Container Instances, so you can deploy only container groups to this subnet. You can also deploy additional container groups in the future to this subnet. You can also attach a Network Security Group (NSG) on this subnet and then only allow Inbound communications from specific private IP addresses.

5) Finally, provide a username and password for the person or the application that wants SFTP access. Please note that you also use SSH keys for authentication (please check this section for more details).

Click on the “Deploy to Azure” button below and fill in the details as shown in the figure below.

Deploy To Azure

SFTP access over Private IP in Azure

Once the deployment is completed, you can see the container group is running on a private IP address as shown in the figure below.

Azure Container Instances over Private IP

Last but not least, copy the private IP address from the container group, and then connect securely to the service with your desired SFTP client such as (FileZilla, or WinSCP).

Prevent SFTP Host Key from Getting Changed

If you have deployed SFTP on Microsoft Azure using Azure Container Instances (ACI), then you probably come across the scenario when the container does an automatic pull of a new image, it restarts the container and the SSH key pairs are getting regenerated. Thus, this causes problems for clients who have the famous trust prompt and break your automation SFTP transfer.

Now there are two possible solutions that you can deploy to solve this issue:

1) The first option is to build a new custom SFTP image by cloning the GitHub repo for the current SFTP container image, then edit the “Dockerfile” to remove the line that removes the host keys.

You can follow the step-by-step guide described here. This option is quite complex and requires deploying a Docker Hub or Azure Container Registry (ACR).

2) Or, you can put the existing ssh key of the image in an Azure file share, mount it to the SFTP image, and then copy it using a bash script to the container. This will keep the ssh keys intact inside the container even after restart. This option will avoid having to build your own fork of the SFTP image as described in option 1 above.

For the remainder of this section, we will describe in detail how to deploy option 2.

Step 1) You need to create two additional file shares in the same storage account that you use for Azure Container Instances. One file share will be used to store the keys, and the second one is to store a bash script.

In this example, I have called my additional file shares: [scripts] and [sshkeys] as shown in the figure below.

File share settings
File share settings

Step 2) Now in the scripts file share, you need to put the following bash script in a file called [copykeys.sh] and then upload it to the file share.

cp /etc/sftpkeys/ssh_host_* /etc/ssh

This bash script just needs to do a copy from the [sftpkeys] folder to ssh.

Bash script to copy sftpkeys
Bash script to copy [sftpkeys]
Step 3) Next, you need to connect to the running SFTP container image, and then copy all four host (private/public) keys from the following path: /etc/ssh and then upload them to the file share called [sshkeys].

Connect to the SFTP container image
Connect to the SFTP container image

You can copy them temporarily using the following command to an existing writable file share and then delete them from that share afterward.

cp /etc/ssh/ssh_host_* /home/sftp1/sftpfileshare01
Copy host keys from /etc/ssh
Copy host keys from /etc/ssh

Step 4) Next, you can connect to the writable SFTP file share using an SFTP client, and download those four host SSH keys as shown in the figure below. Alternatively, you can browse the writable file share directly in the Azure portal and download them.

Download SSH host keys
Download SSH host keys

And then upload them to the new file share called [sshkeys].

Upload SSH host keys to the new file share
Upload SSH host keys to the new file share

Very Important! Don’t forget to delete the host (private/public) keys from the writable file share and from your local system for security reasons. Only the admin must have access to the new file share [sshkeys].

Step 5) Last but not least, you need to mount the new [sshkeys] file share to the container volume path /etc/sftpkeys.

You also need to mount the new [scripts] file share with the bash script to /etc/sftp.d, which is a folder where the atmoz/sftp image will run any script after startup (you can see SFTP atmoz documentation here). The bash script just needs to copy from the /sftpkeys mount folder to the /ssh folder.

Please note that the new file shares [sshkeys] and [scripts] are mounted in Read-Only mode as shown in the figure below.

Mounting the new Azure file shares in Read-Only mode
Mounting the new Azure file shares in Read-Only mode

To do that, you need to update and modify the ARM template for your existing storage account to include the following two sections:

Under “volumeMounts”: [  ]

"volumeMounts": [
    {
        "mountPath": "[concat('/home/', parameters('sftpUser1'), '/', parameters('existingFileShareName1'))]",
        "name": "[parameters('existingFileShareName1')]",
        "readOnly": false
    },
    {
        "mountPath": "[concat('/home/', parameters('sftpUser2'), '/', parameters('existingFileShareName2'))]",
        "name": "[parameters('existingFileShareName2')]",
        "readOnly": false
    },
     {
        "mountPath": "/etc/sftpkeys",
        "name": "[parameters('existingFileShareName3')]",
        "readOnly": true
    },
     {
        "mountPath": "/etc/sftp.d",
        "name": "[parameters('existingFileShareName4')]",
        "readOnly": true
    }
]

And under the “volumes”: [  ] section:

"volumes": [
    {
        "name": "[parameters('existingfileShareName1')]",
        "azureFile": {
            "readOnly": false,
            "shareName": "[parameters('existingfileShareName1')]",
            "storageAccountName": "[parameters('existingStorageAccountName')]",
            "storageAccountKey": "[listKeys(variables('storageAccountId'),'2019-06-01').keys[0].value]"
        }
    },
    {
        "name": "[parameters('existingfileShareName2')]",
        "azureFile": {
            "readOnly": false,
            "shareName": "[parameters('existingfileShareName2')]",
            "storageAccountName": "[parameters('existingStorageAccountName')]",
            "storageAccountKey": "[listKeys(variables('storageAccountId'),'2019-06-01').keys[0].value]"
        }
    },
    {
        "name": "[parameters('existingfileShareName3')]",
        "azureFile": {
            "readOnly": true,
            "shareName": "[parameters('existingfileShareName3')]",
            "storageAccountName": "[parameters('existingStorageAccountName')]",
            "storageAccountKey": "[listKeys(variables('storageAccountId'),'2019-06-01').keys[0].value]"
        }
    },
    {
        "name": "[parameters('existingfileShareName4')]",
        "azureFile": {
            "readOnly": true,
            "shareName": "[parameters('existingfileShareName4')]",
            "storageAccountName": "[parameters('existingStorageAccountName')]",
            "storageAccountKey": "[listKeys(variables('storageAccountId'),'2019-06-01').keys[0].value]"
        }
    }
]

Please have a look at the following ARM template for more information on how to update and mount the new file shares for [sshkeys] and [scripts].

Step 6) Go ahead and redeploy the ARM template with the updated information. If we look under the Logs section of the container instances, we can see now that the container copied the ssh keys successfully as shown in the figure below.

Running /etc/sftp.d/copykeys.sh
Running /etc/sftp.d/copykeys.sh

Step 7) Finally, you can test by stopping or restarting the SFTP container multiple times and see that the ssh keys won’t be changed anymore. Enjoy :)

SFTP ACI and Azure Files Pricing

Let’s take a look at the entire solution costs based on Azure Container Instance (ACI) and Azure File Shares with the following real-world example based on the (West US 2) region.

We use SFTP to back up our legacy system on-premises, hence, the upload is more than the download based on our use case.

> Monthly upload (write) of 100 GB.

> Monthly download (read) 28 GB.

For ACI, the price depends on the number of vCPU and GBs of memory requested for the container group. You are charged based on the vCPUs request for your container group rounded up to the nearest whole number for the duration (measured in seconds) your instance is running. You are also charged for the GB Memory request for your container group rounded up to the nearest tenth place for the duration (measured in seconds) your container group is running.

Please note that if you are going to update the CPU resource (for example, old \”4 vCPUs\” to new \”2 vCPUs\”) for a container group, then you must delete it first and then create a new one.

In this example, we are using a Linux ACI with 2 vCPUs and 1 GB of Memory.

DescriptionPrice in US Dollar
Azure Container group 2 vCPU ($29.5650 per vCPU)$59.13
Azure Container group 1 GB Memory ($3.2485 per GB)$3.2485
Azure file share storage cost 100 GiB ($0.0255 per GB) - Hot Tier$2.55
Azure file share metadata cost at-rest for 100 GiB ($0.027 per GiB) - Hot Tier$2.7
Upload 100 GiB Write transactions ($0.065 per 10,000) - Hot Tier$6.5
List transactions ($0.065 per 10,000) - Hot Tier$0.065
Download 28 GiB Read transactions ($0.0052 per 10,000) - Hot Tier$0.145
All other operations ($0.0052 per 10,000) - Hot Tier$0.0052
Total cost per month$74.35

The Network Ingress cost is free. However, the upload translated to a transaction on Azure Files service – each upload translates to multiple API calls. So, the files transaction prices apply which are calculated in the above table.

To learn more, please refer to the pricing page under the Transactions and data transfer section.

Please note that the price example above is approximate and will vary based on your environment and use case.

Limitations

At the time of this writing (in August 2022), please note that the number of volumes or Azure file shares per container group is a maximum of 20.

So, if you want to have more than 20 SFTP users per container group and each has its own file share, the ACI deployment will fail.

Microsoft does not support quota increases for the type of quota to increase the number of volumes per container group at this time.

However, if you would like to see this capability offered in the future, you may create a new feature request for the ACI engineering team at the Azure feedback ACI forum.

The documentation on increasable ACI quota limits can be found at Service quotas and region availability – Azure Container Instances.

Summary

In this article, we showed you how to deploy an SFTP service based on Azure Container Instance (ACI) and Azure File Shares in two different scenarios. However, if you want to deploy a secure FTP with Azure blob storage without using ACI, then you can create an SFTP service based on Files.com today, and then sync your data to Microsoft Azure blob storage. This is a great solution because your data can be mounted directly or synced to/from Microsoft Azure, thus reducing additional storage costs.

Updated – 17/11/2021 – After more than two years of waiting, finally Microsoft released a fully managed SFTP (PaaS) service based on Microsoft Azure Blob Storage. Check the following article on how to enable SFTP support for Azure Storage step-by-step.

So if you want a fully manageable SFTP solution in Azure, you can create an SFTP service based on Azure Container Instance (ACI), and then once the PaaS solution is available, you can switch and copy your data from Azure File Share to Blob Storage. Your data will be intact.

__
Thank you for reading my blog.

If you have any questions or feedback, please leave a comment.

-Charbel Nemnom-

Photo of author
About the Author
Charbel Nemnom
Charbel Nemnom is a Senior Cloud Architect, Swiss Certified ICT Security Expert, Certified Cloud Security Professional (CCSP), Certified Information Security Manager (CISM), Microsoft Most Valuable Professional (MVP), and Microsoft Certified Trainer (MCT). He has over 20 years of broad IT experience serving on and guiding technical teams to optimize the performance of mission-critical enterprise systems with extensive practical knowledge of complex systems build, network design, business continuity, and cloud security.
Previous

How To Set Multiple IP Addresses on One NSG Rule in Azure Stack

Passed Exam: Business Continuity Management Based on ISO/IEC 22301

Next

93 thoughts on “How to Deploy a Secure FTP (SFTP) Service on Microsoft Azure”

Leave a comment...

  1. Hello Charbel, thank you for this tutorial. However, I’m having issues with the whitelisting functionality.
    The ALLOW/DENY configuration Nginx rules are not being applied as expected. I am able to successfully follow all of the steps and read/write the SFTP site through the reverse proxy port 2222, but upon testing, I am still able to access the site no matter what IP I use, regardless of the rules. Did you test this? I believe that the ACI is doing internal proxying of some sort after I attempt to connect remotely. In other words, the real client IP is being replaced by an internal one. Therefore, the ALLOW/DENY rules are not being applied.

    I followed the steps to access the SFTP site with a single username/password with minimal edits to your suggestion aside from my IP whitelisting.

  2. Hello TJ, thanks for your comment. Yes, you are right. I saw the same thing during my testing.
    After investigating, I found out that the Azure Container Instance is not preserving the client’s IP address.
    I am checking with the team to see when they will support preserving the client IP address so we can filter incoming public IP addresses.
    In the meantime, you could put the ACI behind e.g. an Azure Firewall or Azure Application Gateway for Public IP restriction, but that only makes sense as part of a wider deployment rather than something in isolation.
    Hope this helps!

  3. Thanks, Charbel for the reply. I have a couple of follow-up questions: (1) can you clarify what you mean by “that only makes sense as part of a wider deployment rather than something in isolation”. My use case is simply creating a standalone Azure-hosted SFTP site where our partners could share their files as one of our ETL sources with access via username and password. Ideally, we could enable whitelisting as added security. FYI the native Azure SFTP PaaS doesn’t work in our case because of limited support for authentication algorithms. (2) I read that there was mention of host keys (fingerprint) automatically rotating every few months which would cause connection errors for my partners who are programmatically placing files on our site each day. Would this be an issue in my case where I’m using username and passwords? I can’t test this because I would have to wait a few months after deployment for that case to occur.

  4. Hello TJ,
    What I meant by “that only makes sense as part of a wider deployment rather than something in isolation” is, that if you have a large Azure deployment, then you could use Azure Application Gateway and Azure Firewall to filter and whitelist IPs, because these services cost additional money and they are not cheap.
    So, If you are leveraging any of these services already, you could integrate SFTP based on ACI and enable whitelisting.
    This does not mean that you can’t use these services only for SFTP, but keep the cost in mind.
    I am totally aware of the native Azure SFTP PaaS, today this solution is not complete yet and cannot fulfill all the requirements. Thus, ACI with Azure Files is a more flexible solution.
    To answer your question about host keys (fingerprint) automatically rotating every few months which would cause connection errors, this is NOT an issue in the case you are using username and passwords.
    But again, I cannot confirm this behavior because every application is different, and we don’t know how the partners are programmatically connecting to SFTP and placing files on your site.
    I am working on another solution to see if I can whitelist IPs without using Azure Application Gateway and Azure Firewall. I will update the guide if it works.
    Thanks!

  5. Do you have an example of the whole solution that you could post with this worked out on the Azure Calculator?

    We only need a max of 100GB of storage.

  6. Thanks for this great article. I have a question regarding the multiple local users for the ACI, where are they stored? Is there a way I can view/create them in the Azure portal, or is scripting/ARM the only way? I want to make it easy for the customer to add new users in the future without the need to edit an ARM template. Thanks in advance!

  7. Hello Baba, thanks for the feedback and comment!
    The users’ data in ACI are stored in Azure File Shares and the profile is in ACI (Linux) container.
    Unfortunately, there is no way to create users in the Azure portal for ACI.
    The only way to add new users as you noted is using ARM Templates or Bicep.
    Please note that you can redeploy the template by adding new users without affecting the existing deployment. It’s incremental.
    Hope it helps!

  8. Hello Charbel,
    I want to add more users to SFTP and increase the number from 3 to 5.
    The info in the template seems correct (shows 5) but it only creates 3 users. Any other parameter I need to update?
    Can this configuration also work with passwords?
    Regards,

  9. Hello Filip, thanks for the comment!
    You need to make sure to add the users under the parameters section (sftpUserCount and userNames), then adjust the sftpEnvVariable under the variables section, and finally, update the volume mounts (volumeMounts) section in the container to match the number of users.
    Yes, this configuration can work with passwords as well.
    I have it deployed for 20 users with passwords instead of SSH (public/private) keys.
    Hope it helps!

  10. Hello Charbel,
    I updated JSON and was able to create the sftp shares for multiple users.
    But this JSON creates a new storage account. Do you have JSON that uses an existing storage account?
    I tried to update myself but get an error.
    Thanks,

  11. Hello, I tried to run this azure template today, and don’t believe that it is creating the users (I am trying to authenticate in and getting an authentication failure out the gate).

  12. Hello Robert, thanks for the comment!
    Could you please let me know which template are you running? because I shared multiple Azure templates here.
    To which section are you referring in this article?
    I’ve deployed the template last week and it’s working as expected.

  13. It is the very first template, I just tried it again, put in the username and passwords, and I get access denied when I try and use them. I can go in after the deployment has finished and reset the username and password (editing the JSON), and redeploy. (the username and password are the same in both instances (copy/paste) so I don’t think I am mistyping anything.
    Status: Access denied
    Error: Authentication failed.
    Error: Critical error: Could not connect to the server

  14. Hello Robert, thanks for sharing more details.
    Please note that I just deployed the following template with usernames and passwords, and I was able to access SFTP without any issue. Could you please do the same?
    Please note that the default FQDN is set to “az-sftp” in the template, please try to change it because it’s already taken.
    You could also try to access it using the Public IP address instead of DNS.
    Hope it helps!

Let me know what you think, or ask a question...

error: Alert: The content of this website is copyrighted from being plagiarized! You can copy from the 'Code Blocks' in 'Black' by selecting the Code. Thank You!