SFTP server

In the Azure portal, choose Create a resource, search for SFTP Server on Ubuntu 24.04 LTS by SecureAnyCloud, and select Create.

Pick your subscription, resource group and region. Choose the Standard_B2s size (SFTP needs little CPU, so size for your users and transfer volume). Choose the administrator account, and use an SSH public key if you can.

Under Networking, allow inbound 22 only from the networks your users and administrators connect from.

The image brings its own 50 GiB data disk for /srv/sftp. You can enlarge it on the Disks tab, and first boot grows the file system to fill it.

To deploy with the Azure CLI, replace the values in angle brackets. The last command limits port 22 to one network:

az group create --name sftp-rg --location <region>
az vm image terms accept --urn sac1647283583153:sftp-server-ubuntu-24-04:default:latest
az vm create --resource-group sftp-rg --name sftp-server \
  --image sac1647283583153:sftp-server-ubuntu-24-04:default:latest \
  --size Standard_B2s --admin-username azureuser \
  --ssh-key-values ~/.ssh/id_rsa.pub --public-ip-sku Standard
az network nsg rule update --resource-group sftp-rg --nsg-name sftp-serverNSG \
  --name default-allow-ssh --source-address-prefixes <your-client-cidr>

ssh azureuser@<vm-public-ip>

The administrator account works like any Ubuntu VM on Azure. Sign in over SSH with the key (or password) you chose at deployment, and use sudo for administration.

First boot creates the demo user and proves an SFTP round trip before it finishes (a few seconds after SSH answers):

systemctl is-active ssh fail2ban sftp-prepare sftp-server-firstboot
sudo test -f /var/lib/sac/data/sftp-server-firstboot.done && echo FIRSTBOOT_DONE

active active active active FIRSTBOOT_DONE

sftp-server-firstboot runs once. After a later reboot it reports inactive, which is expected because the marker file stays in place.

Only sshd listens on a public address, on port 22:

sudo ss -lntp | awk 'NR>1 {print $4, $6}' | grep -v '127.0.0' | sort

0.0.0.0:22 users:(("sshd",...)) [::]:22 users:(("sshd",...))

sudo grep -vE '^(#|$)' /root/sftp-server-info.txt

The file is readable by root only:

SFTP_HOST=<vm-public-ip> SFTP_PORT=22 SFTP_DEMO_USER=sftpdemo SFTP_DEMO_KEY=/root/sftp-demo-key SFTP_DEMO_KEY_FINGERPRINT=SHA256:<demo-key-fingerprint> SFTP_DEMO_JAIL=/srv/sftp/sftpdemo SFTP_PASSWORD_AUTH=off SFTP_ADMIN_USER=azureuser HOST_KEY_ED25519_SHA256=SHA256:<this-VM's-ed25519-host-key> HOST_KEY_ECDSA_SHA256=SHA256:<this-VM's-ecdsa-host-key> HOST_KEY_RSA_SHA256=SHA256:<this-VM's-rsa-host-key>

SFTP_HOST is the VM's public IP address from Azure instance metadata (the private address when the VM has no public IP). To print a DNS name there instead, put it in /etc/sac/sftp-hostname before first boot. First boot is the only part of the image that reads instance metadata, and it cannot reach the WireServer.

The first time any client connects, it shows the server's host key fingerprint and asks whether to trust it. It must equal one of the HOST_KEY_* values. If it does not, do not connect. You can print the fingerprints at any time:

for t in ed25519 ecdsa rsa; do ssh-keygen -l -E sha256 -f /etc/ssh/ssh_host_${t}_key.pub; done

The demo user sftpdemo exists so you can try the server straight away. Its private key, unique to your VM, is /root/sftp-demo-key. Copy it to your own computer over your administrator SSH session, then connect:

ssh azureuser@<vm-public-ip> 'sudo cat /root/sftp-demo-key' > sftp-demo-key chmod 600 sftp-demo-key sftp -i sftp-demo-key sftpdemo@<vm-public-ip> sftp> cd upload sftp> put report.csv sftp> ls -l sftp> bye

The built-in check runs the same kind of session on the VM itself: an upload and a byte-for-byte download, the audit log entries, the jail, and the refusals (no shell, no terminal, no forwarding, no root login, no password while passwords are off):

sudo sftp-verify.sh | tail -7

ok TCP forwarding (-W 169.254.169.254:80) refused: administratively prohibited ok remote forwarding (-R) refused by the server (rc 255) ok root login refused (Permission denied) ok the demo key does not open the administrator account (azureuser) ok password authentication not offered to sftpdemo (key only: 'Permission denied (publickey)') SFTP_ROUNDTRIP_OK target 10.0.0.4

Once your own users exist, remove the demo user and its key with sudo sftp-deluser sftpdemo --yes && sudo shred -u /root/sftp-demo-key /root/sftp-demo-key.pub. After that, sftp-verify.sh has no account to test with.

Ask the user for their public key (the .pub file) and add it with --ssh-key @<file> (or paste the key line in quotes). --quota caps the user's storage. This example makes a key pair on the VM only to show the whole flow. In practice, the user keeps the private key and sends you the public one:

[ -f /tmp/bob_key ] || ssh-keygen -q -t ed25519 -N '' -C bob -f /tmp/bob_key
sudo sftp-adduser bob --ssh-key @/tmp/bob_key.pub --quota 10G

SFTP user "bob" ready. jail (chroot) : /srv/sftp/bob writable: /srv/sftp/bob/upload ssh key : added to /etc/ssh/authorized_keys.d/bob quota : 10G

The key is stored in /etc/ssh/authorized_keys.d/bob, owned by root and outside the jail, with OpenSSH's restrict option. A private key is refused if it is passed by mistake. Bob can now upload and download:

printf 'put /etc/hostname upload/hello.txt\nls -l upload\n' > /tmp/bob.batch sftp -i /tmp/bob_key -o StrictHostKeyChecking=accept-new -o UserKnownHostsFile=/tmp/bob_known_hosts -b /tmp/bob.batch bob@127.0.0.1

sftp> put /etc/hostname upload/hello.txt sftp> ls -l upload -rw-r----- ? 1001 1001 12 Oct 25 10:10 upload/hello.txt

New files are created with mode 0640 (owner read-write, group read).

Passwords are off for SFTP users on a fresh VM. Creating a user with --password generate switches password logins on for the sftpusers group only and prints a new 24-character password once, so store it straight away:

sudo sftp-adduser alice --password generate --quota 5G Note: SFTP password authentication is now ON for the sftpusers group (the administrator account is unaffected). SFTP user "alice" ready. jail (chroot) : /srv/sftp/alice writable: /srv/sftp/alice/upload quota : 5G GENERATED PASSWORD for alice (shown once, store it now): <24-character password>

To choose the password yourself, pass it on standard input and never on the command line. A command line ends up in your shell history and in sudo's log, so the tools refuse --password <value>:

read -rs PW && printf '%s\n' "$PW" | sudo sftp-adduser carol --password-stdin; unset PW

Check or change the setting at any time:

sudo sftp-password-auth status

SFTP password authentication: OFF (key only)

sudo sftp-password-auth on writes /etc/ssh/sshd_config.d/64-sac-sftp-password.conf (a Match Group sftpusers block with PasswordAuthentication yes). sudo sftp-password-auth off removes it. It never changes how the administrator signs in.

Moving a password user to keys: add their public key with sudo sftp-adduser <user> --ssh-key @<user>.pub, lock the password with sudo sftp-passwd <user> --lock (no password hash is kept), and once no one uses passwords, run sudo sftp-password-auth off.

fail2ban bans an address after 5 failed logins in 10 minutes (1 hour at first, growing to a week for repeat offenders).

sudo sftp-listusers

USER PASSWORD KEYS QUOTA USED JAIL bob no 1 10240M 4.0K /srv/sftp/bob sftpdemo no 1 5120M 4.0K /srv/sftp/sftpdemo

Command Purpose

sftp-adduser <user> [--ssh-key @<file>] [--password generate \| --password-stdin] [--quota 10G] Create a user, or add a key, password or quota to one

sftp-passwd <user> generate \| --password-stdin \| --lock New password (printed once or read from standard input), or lock it

sftp-deluser <user> [--yes \| --keep-data] Remove a user and clear its quota limit; --yes also deletes /srv/sftp/<user>

sftp-listusers [--json] Users, password set, number of keys, quota, usage

sftp-password-auth on \| off \| status SFTP password logins for the sftpusers group

sftp-verify.sh, sftp-healthcheck The built-in end-to-end check and a quick health check

All of them need sudo. They refuse to touch an account that is not an SFTP user.

sudo ls -la /srv/sftp/bob

drwxr-xr-x 4 root root 4096 Oct 25 10:10 . drwxr-xr-x 5 root root 4096 Oct 25 10:10 .. drwxr-xr-x 2 root root 4096 Oct 25 10:10 dev drwxr-x--- 2 bob sftpusers 4096 Oct 25 10:10 upload

The jail root belongs to root (OpenSSH requires this), so the user cannot change it. upload is the user's own directory. dev holds only the socket that carries the audit log to the journal (Step 10). From the user's side, / is the jail, .. leads nowhere and system files do not exist:

printf 'pwd\ncd ..\npwd\nls /\n' > /tmp/bob.batch2 sftp -i /tmp/bob_key -o UserKnownHostsFile=/tmp/bob_known_hosts -b /tmp/bob.batch2 bob@127.0.0.1

sftp> pwd Remote working directory: / sftp> cd .. sftp> pwd Remote working directory: / sftp> ls / /dev /upload

An SFTP account cannot run commands either:

ssh -i /tmp/bob_key -o BatchMode=yes -o UserKnownHostsFile=/tmp/bob_known_hosts bob@127.0.0.1 id || true

This service allows sftp connections only.

The effective sshd settings for an SFTP user and for the administrator show the difference (replace azureuser with your administrator name if you chose another):

sudo sshd -T -C user=bob,host=client,addr=198.51.100.7 | grep -E '^(forcecommand|chrootdirectory|allowtcpforwarding|disableforwarding|permittty|authorizedkeysfile|passwordauthentication) '
sudo sshd -T -C user=azureuser,host=client,addr=198.51.100.7 | grep -E '^(permitrootlogin|forcecommand|chrootdirectory) '

passwordauthentication no permittty no allowtcpforwarding no disableforwarding yes forcecommand internal-sftp -u 0027 -l INFO chrootdirectory /srv/sftp/%u authorizedkeysfile /etc/ssh/authorized_keys.d/%u permitrootlogin no forcecommand none chrootdirectory none

The SFTP settings live in /etc/ssh/sshd_config.d/65-sac-sftp.conf and apply to members of the sftpusers group only. They keep SFTP users key-only even if you chose password sign-in for the administrator.

/etc/ssh/sshd_config.d/00-sac.conf refuses root logins, empty passwords and X11 forwarding for everyone. The administrator's password setting is the one you picked in the portal, and cloud-init writes it to 50-cloud-init.conf.

Every SFTP session and file operation is in the journal, with the client's address taken from the connection:

sudo journalctl -t internal-sftp --no-pager -n 8 -o cat

session opened for local user bob from [127.0.0.1] open "/upload/hello.txt" flags WRITE,CREATE,TRUNCATE mode 0644 close "/upload/hello.txt" bytes read 0 written 12 opendir "/upload/" closedir "/upload/" session closed for local user bob from [127.0.0.1]

A removal shows as remove name "/upload/<file>". OpenSSH writes these lines from inside the jail, where there is normally no log socket, so they would be lost. The image binds the journal's socket into each jail as dev/log at every boot (sftp-prepare.service) and whenever sftp-adduser creates a user. Logins and refusals are in sshd's own log: sudo journalctl -u ssh.

fail2ban watches sshd's log and bans an address after repeated failed logins:

sudo fail2ban-client status sshd

Status for the jail: sshd |- Filter | |- Currently failed: 0 | |- Total failed: 0 | `- Journal matches: _SYSTEMD_UNIT=ssh.service + _COMM=sshd `- Actions |- Currently banned: 0 |- Total banned: 0 `- Banned IP list:

To lift a ban, run sudo fail2ban-client set sshd unbanip <address>.

The image points fail2ban at ssh.service, the unit that sshd actually runs as. Ubuntu's stock filter watches sshd.service and would never ban anything.

sshd, fail2ban and the boot preparation are blocked from the Azure instance metadata service and the WireServer. First boot may read instance metadata (for the host address and the administrator name) but not the WireServer. SFTP users cannot reach either, because they cannot run commands or forward connections.

systemctl show -p IPAddressDeny ssh fail2ban sftp-prepare sftp-server-firstboot

IPAddressDeny=169.254.169.254/32 168.63.129.16/32 IPAddressDeny=169.254.169.254/32 168.63.129.16/32 IPAddressDeny=169.254.169.254/32 168.63.129.16/32 IPAddressDeny=168.63.129.16/32

Each blocked unit checks this from the inside every time it starts:

sudo journalctl -u ssh -u fail2ban -u sftp-prepare -b -o cat --no-pager | grep -E '^METADATA_' | sort | uniq -c

3 METADATA_BLOCKED 168.63.129.16 3 METADATA_BLOCKED 169.254.169.254

df -h /srv/sftp findmnt -no OPTIONS /srv/sftp

Filesystem Size Used Avail Use% Mounted on /dev/sdc 49G 60K 47G 1% /srv/sftp rw,nosuid,nodev,noexec,relatime,quota,usrquota,grpquota

/srv/sftp is its own Azure data disk (ext4, mounted by UUID with nodev,nosuid,noexec), so you can snapshot, resize or move it on its own.

To grow it, resize the disk in Azure. At the next boot, sftp-prepare.service grows the file system. Or run sudo resize2fs $(findmnt -no SOURCE /srv/sftp) straight away.

Quotas are enforced by the usrquota,grpquota mount options at every mount, so they survive reboots. An upload that would exceed a user's quota is refused with "Disk quota exceeded". Removing a user clears its limit, so a new account that later gets the same user ID starts without one.

To see each user's usage and limit (in KiB), run:

sudo repquota -u /srv/sftp | sed -n '1,3p;/bob\|sftpdemo/p'

The ext4 quota format needs the kernel's quota_v2 module. On the current Azure kernel it is part of the kernel's own modules package, which every kernel update installs together with the new kernel. On older Azure kernels, which kept it in linux-modules-extra, the image installs the matching metapackage instead. The file below records which applies to your VM:

modinfo -F filename quota_v2 cat /etc/sac/sftp-quota-kernel-meta

OpenSSH is Ubuntu's package, so apt and unattended-upgrades keep it patched along with the rest of the system. The installed version and where it came from:

dpkg-query -W openssh-server cat /usr/local/share/doc/sac-sftp/SOURCE.txt

After an OpenSSH update, sudo systemctl restart ssh makes the running server use it (open SFTP sessions are not interrupted).

Component Version Path

OpenSSH server (sshd, internal-sftp) 9.6p1, Ubuntu 1:9.6p1-3ubuntu13 (updated by apt) /usr/sbin/sshd

fail2ban Ubuntu 24.04 package /etc/fail2ban/jail.d/sac-sshd.conf

Ubuntu 24.04 LTS

Path Purpose

/etc/ssh/sshd_config.d/00-sac.conf No root login, no empty passwords, no X11 forwarding (for everyone)

/etc/ssh/sshd_config.d/64-sac-sftp-password.conf Present only while SFTP password logins are on

/etc/ssh/sshd_config.d/65-sac-sftp.conf The SFTP jail for the sftpusers group (key only by default)

/etc/ssh/authorized_keys.d/<user> SFTP users' public keys

/srv/sftp/<user> Each user's jail; upload/ is writable

/root/sftp-server-info.txt Connection details and host key fingerprints (mode 0600)

/root/sftp-demo-key The demo user's private key (mode 0600)

/usr/local/sbin/sftp-* Account tools, checks, the metadata probe and the per-boot preparation

/usr/local/share/doc/sac-sftp/SOURCE.txt Version and source notes

Sign in to the AWS Management Console, open the EC2 service, and select Launch instance. Under Application and OS Images, choose AWS Marketplace AMIs and search for SFTP Server. Select the SecureAnyCloud listing and choose Select, then Continue on the subscription summary.

Pick an instance type of m5.large or larger as a balanced default. Size the instance to the number of users and the transfer volume you expect. Choose your EC2 key pair under Key pair (login) for administrator access. Under Network settings select your VPC and subnet, and either create or select a security group that allows inbound port 22 from the networks your SFTP users connect from. SFTP rides on the SSH port, so only port 22 is required.

Select Launch instance. First-boot initialization takes only a few seconds after the instance state becomes Running and the status checks pass.

The following block launches an instance from the SecureAnyCloud SFTP Server Marketplace AMI into an existing subnet and security group. Replace <ami-id> with the AMI ID shown on the Marketplace listing, <key-name> with your EC2 key pair name, <subnet-id> with your subnet ID, and <security-group-id> with a security group that opens port 22 from the networks your users connect from.

aws ec2 run-instances \
  --image-id <ami-id> \
  --instance-type m5.large \
  --key-name <key-name> \
  --subnet-id <subnet-id> \
  --security-group-ids <security-group-id> \
  --block-device-mappings '{"DeviceName":"/dev/sda1","Ebs":{"VolumeSize":30,"VolumeType":"gp3"}}' \
  --metadata-options 'HttpTokens=required,HttpEndpoint=enabled' \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=sftp-server}]'

The image attaches a dedicated 50 GiB SFTP storage volume automatically, mounted at /srv/sftp, where every user's chroot home directory lives. To start with more storage, enlarge that volume on the Storage step in the console, or add a second block device mapping on the CLI.

Connect to the instance with SSH as the default login user for the operating system variant you launched. The administrator account is key-only. The login user differs by variant:

Operating system variant SSH login user

Ubuntu 26.04 ubuntu

Replace <key-file> with the path to your private key file and <instance-public-ip> with the public IP address or DNS name of the instance.

ssh -i <key-file> ubuntu@<instance-public-ip>

All of the user management commands below are run as the administrator with sudo.

On first boot the server creates a demo SFTP user named sftpdemo with a fresh SSH key unique to your instance. 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 (see Step 8). The demo user is confined to its own home directory, exactly like any user you create. Once your own users exist, remove the demo user:

sudo sftp-deluser sftpdemo --yes

The image ships key-only. Password authentication is disabled by default, which is the secure baseline and is required to pass the AWS Marketplace image scan. SSH key users work immediately. To allow 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.

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.

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.

Cap how much storage a user can consume with --quota. This protects the shared volume so that no single user can fill the disk. 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

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 are prompted for the password):

sftp alice@<instance-public-ip>

A key-based user connects with their private key:

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

Once connected, a user can upload and download files inside the 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:

Setting Value

Protocol SFTP (SSH File Transfer Protocol)

Host the instance public IP or DNS name

Port 22

Username the SFTP user name, for example alice

Password or key the generated password, or the user's private key

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.

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.

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:

Command Purpose

sftp-adduser <name> [--password generate\|<value>] [--ssh-key @file\|"key"] [--quota <size>] Create or update an SFTP user

sftp-passwd <name> [--password <value>\|generate\|--lock] Set, generate or lock a user's password

sftp-listusers [--json] List users with auth method, key count and usage

sftp-deluser <name> [--keep-data] [--yes] Remove a user, optionally with their data

The image is hardened out of the box, and you can tighten it further:

• Brute-force protection. fail2ban watches for repeated failed logins on port 22 and bans offending addresses with an increasing ban time. Check the jail and currently banned addresses with sudo fail2ban-client status sshd.
• Network exposure. Restrict the inbound port 22 rule in the instance's security group to the specific networks your users and administrators connect from, rather than leaving it open to the whole internet.
• Administrator access. The administrator account accepts SSH keys only. Password authentication is disabled for it, so only SFTP users in the sftpusers group can use passwords.
• Dedicated volume. Snapshot and resize the /srv/sftp volume independently of the operating system disk to back up or grow user storage on its own schedule.