SFTP Server on Ubuntu 24.04 on Azure User Guide

Overview

This image runs a production ready SFTP file transfer server built on OpenSSH, the open source secure shell suite. The SFTP service is fully configured and security hardened, so you can onboard users and move files securely within minutes of launch without hand editing the SSH daemon configuration.

Every SFTP user is locked into their own home directory with an OpenSSH chroot jail. A user can only see and write inside their own space, never the rest of the filesystem, and is given no interactive shell. User home directories live on a dedicated, independently resizable Azure data disk mounted at /srv/sftp, kept separate from the operating system disk. The data disk is part of the image, so every VM you deploy is provisioned with it automatically.

The image ships key only, which is the secure default. SFTP users authenticate with an SSH key out of the box, and you can enable password authentication for SFTP users with a single command (it is also turned on automatically the first time you create a password user). The administrator account always stays key only. A small set of management tools, sftp-adduser, sftp-deluser, sftp-listusers, sftp-passwd and sftp-password-auth, is the primary interface to the server. The image is hardened by default with fail2ban brute force protection, per user disk quotas, and transfer audit logging that records every upload, download and delete to the system journal.

On the first boot of every deployed VM, a one shot service creates a demo SFTP user named sftpdemo with a fresh SSH key unique to that VM and records its details in a root only file, so you can confirm the server works immediately and then remove it once your own users exist.

What is included:

• OpenSSH SFTP server (Ubuntu 24.04 noble main), chroot-jailed per user
• Dedicated 50 GiB data disk at /srv/sftp (ext4, per-user quotas) — separate from the OS disk
• Management tools in /usr/local/sbin: sftp-adduser, sftp-deluser, sftp-listusers, sftp-passwd, sftp-password-auth
• fail2ban sshd jail (brute-force protection), SFTP transfer audit logging to the journal
• Key-only baseline; SFTP password auth enabled on demand; admin always key-only
• Per-VM demo user sftpdemo created at first boot, details in /root/sftp-server-info.txt
• 24/7 cloudimg support

Prerequisites

Before you deploy this image you need:

• An active Microsoft Azure subscription where you can create virtual machines
• An SSH key pair for administrator access to the VM
• A virtual network and subnet in the target region, with a network security group (NSG) allowing inbound port 22 from the networks your SFTP users and administrators connect from
• The Azure CLI installed locally if you plan to deploy from the command line, and an SFTP client (the sftp command line tool, FileZilla, Cyberduck or WinSCP) to connect as a user

Standard_B2s (2 vCPU / 4 GiB RAM) is a balanced default; size the VM to the number of users and the transfer volume you expect. SFTP rides on the SSH port, so only inbound port 22 is required on the NSG.

Step 1: Deploy from the Azure Marketplace

Sign in to the Azure Portal, choose Create a resource, and search the Marketplace for SFTP Server by cloudimg. Select the listing and choose Create.

On the Basics tab pick your subscription and resource group, a region, and a VM size (Standard_B2s or larger). Under Administrator account select SSH public key, set the username, and paste your public key. Under Inbound port rules allow SSH (22). Review the dedicated data disk on the Disks tab — it is included in the image and carries your SFTP users' home directories. Select Review + create, then Create. First-boot initialisation completes within a few seconds of the VM reaching the Running state.

Step 2: Deploy from the Azure CLI

The following block creates a VM from the cloudimg SFTP Server image into an existing VNet and subnet. Replace the placeholders with your own values. The dedicated /srv/sftp data disk is part of the image and is attached automatically.

az vm create \
  --resource-group <your-rg> \
  --name sftp-server \
  --image <marketplace-image-urn> \
  --size Standard_B2s \
  --admin-username azureuser \
  --ssh-key-values ~/.ssh/id_ed25519.pub \
  --vnet-name <your-vnet> --subnet <your-subnet> \
  --public-ip-sku Standard

az vm open-port --resource-group <your-rg> --name sftp-server --port 22

Step 3: Connect as the Administrator over SSH

Connect to the VM with SSH as the administrator user you set at deploy time (azureuser by default on Ubuntu). The administrator account is SSH key only.

ssh azureuser@<vm-public-ip>

Step 4: The Built In Demo User

On first boot the server creates a demo SFTP user named sftpdemo with a fresh SSH key unique to your VM. Read its details and the path to its private key from the root only information file:

sudo cat /root/sftp-server-info.txt

The demo user's private key is written to /root/sftp-demo-key. Copy it to your client to connect as the demo user and confirm the server works. The demo user is confined to its own home directory, exactly like any user you create. Once your own users exist you should remove the demo user in production:

sudo sftp-deluser sftpdemo --yes

Step 5: Authentication Model

The image ships key only: password authentication is disabled by default, which is the secure baseline. SSH key users work immediately. When you want password logins for SFTP users, enable them with one command (the administrator account always remains key only):

sudo sftp-password-auth on

Check or turn the setting off at any time with sudo sftp-password-auth status and sudo sftp-password-auth off. Creating a password based user (next step) turns this on for you automatically.

Step 6: Create a Password Based SFTP User

Create a user who authenticates with a password. The --password generate option creates a strong random password and prints it once; give it to the user over a secure channel. To set a specific password instead, use --password '<value>'. The first time you create a password user, SFTP password authentication is enabled automatically.

sudo sftp-adduser alice --password generate

The tool creates the account with no shell, adds it to the sftpusers group, and builds the chroot home directory at /srv/sftp/alice with a single user writable subdirectory, upload. The user connects on port 22 and lands directly in their home directory.

Step 7: Create an SSH Key Based SFTP User

Create a user who authenticates with an SSH key. Pass the user's public key with --ssh-key, either inline or, as shown here, from a file with the @ prefix. This example generates a demonstration key pair first; in practice the user supplies their own public key.

ssh-keygen -t ed25519 -f /tmp/bob_key -N '' -q
sudo sftp-adduser bob --ssh-key @/tmp/bob_key.pub

The public key is stored in the central, root owned location /etc/ssh/authorized_keys.d/bob, outside the user's jail, so the key cannot be tampered with by the user and the chroot ownership rules are always satisfied. A key based user created without a password cannot log in with a password at all. You can give a user both a password and a key by passing both options.

Step 8: Per User Disk Quotas

Cap how much storage a user can consume with --quota. This protects the shared data disk so that no single user can fill it. The size accepts a G, M or K suffix.

sudo sftp-adduser carol --password generate --quota 10G

You can review every user's state, including the number of keys and current upload directory usage, at any time:

sudo sftp-listusers

Step 9: Connecting as an SFTP User

SFTP users connect on port 22 and are dropped straight into their home directory; their only writable area is the upload directory. From the sftp command line client, a password user connects like this (they will be prompted for the password):

sftp alice@<vm-public-ip>

A key based user connects with their private key:

sftp -i bob_key bob@<vm-public-ip>

Once connected, a user uploads and downloads files inside their upload directory:

sftp> cd upload
sftp> put localfile.txt
sftp> get remotefile.txt
sftp> bye

The server works with any standard SFTP client. In a graphical client, use these settings:

Step 10: How the Home Directory Lock Works

Every SFTP user is confined to their own directory by an OpenSSH chroot jail. The jail root, the user's home directory, is owned by root and is not writable by the user; this is an OpenSSH requirement and is what makes the lock secure. Inside it, a single upload directory is owned by the user and is where they read and write files.

sudo ls -la /srv/sftp/alice

A locked user cannot leave their home directory, cannot see other users' files, and cannot reach the rest of the operating system. Listing the root of their session shows only the upload directory, and attempts to retrieve a system file such as /etc/passwd fail because that path does not exist inside the jail.

Step 11: Transfer Audit Logging

Every SFTP session and every file operation, upload, download, rename and delete, is recorded to the system journal for compliance and troubleshooting. Review the audit trail with:

sudo journalctl -t internal-sftp --no-pager --since today | tail -20

Each entry records the user, the operation and the path, so you have a complete record of who transferred what and when.

Step 12: Managing Users

Reset or lock a user's password at any time. Locking the password leaves any SSH key the user has in place:

sudo sftp-passwd alice generate

Remove a user when they no longer need access. By default the account is removed and you are reminded that the data remains; add --yes to delete the user's files as well, or --keep-data to keep them deliberately:

sudo sftp-deluser bob --yes

The full set of management tools is:

Step 13: Hardening Notes

The image is hardened out of the box: password authentication is off by default and the administrator account is key only; every SFTP user is chroot jailed with no shell and no port, agent or X11 forwarding; fail2ban bans repeat offenders on the SSH port; per user disk quotas stop any one account filling the data disk; and every transfer is audit logged to the journal. Keep the OS patched (sudo apt update && sudo apt upgrade), restrict inbound port 22 on the NSG to the networks your users connect from, and prefer SSH key authentication over passwords where you can.

Support

This image is backed by 24/7 cloudimg support. Contact us by email and chat for help with SFTP user onboarding, key management, chroot configuration, quotas, auditing and secure file transfer architecture.

All product and company names are trademarks or registered trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.