Configure SFTP for Active Directory Users with SSSD on RHEL 10

SFTP is provided by OpenSSH, so you do not need a separate FTP server.

When the RHEL host is already joined to Active Directory through SSSD, an AD user such as jane@lab.example can normally use SFTP through the same SSH authentication stack.

For new file-transfer setups on RHEL 10, use SFTP instead of building a new FTP/vsftpd deployment.

Quick answer

              SFTP client
                   ↓
                 sshd
                   ↓
    AD password → PAM → SSSD → Active Directory
                   or
            SSH public key
                   ↓
         User home directory

Password authentication reaches Active Directory through PAM and SSSD. Public-key authentication is handled by SSH separately.

Prerequisite: realmd + SSSD domain join with client-software: sssd.

Test environment

Verify Active Directory identity

Before changing anything in SSH, make sure the Linux host is still joined to AD through SSSD:

realm list

In the output, check that client-software is sssd. The login-formats line also tells you which username format SSSD expects.

Check that the AD user resolves on the host:

id jane@lab.example

Now check how Linux sees the AD account. getent shows the user’s UID, group, home directory, and login shell:

getent passwd jane@lab.example

jane@lab.example:*:758601105:758600513::/home/jane@lab.example:/bin/bash

Here, Jane’s home directory is /home/jane@lab.example. That is where a normal SFTP session will start.

Restrict which AD users may connect

If the server uses realm permit to restrict AD logins, make sure the SFTP user is allowed:

sudo realm permit jane@lab.example

For several users, permit an AD group instead of adding accounts one at a time:

sudo realm permit -g 'network-admins@lab.example'

If id finds the user but login still fails, check the realm access policy before changing SSH settings.

Verify OpenSSH and the SFTP subsystem

Make sure sshd is running before you test:

sudo systemctl enable --now sshd

RHEL can load SSH settings from both sshd_config and files under sshd_config.d. Use sshd -T to see the settings that are actually in effect:

sudo sshd -T | grep -E 'usepam|passwordauthentication'

Check that the SFTP subsystem is defined:

grep -R '^Subsystem.*sftp' /etc/ssh/sshd_config /etc/ssh/sshd_config.d/ 2>/dev/null

Subsystem	sftp	/usr/libexec/openssh/sftp-server

This line tells sshd which SFTP server program to start when an SFTP client connects.

Verify automatic home directory creation

AD users normally do not have a local home directory until their first login. If the with-mkhomedir authselect feature is enabled, PAM creates it automatically:

authselect current

You should see with-mkhomedir among the enabled features.

oddjobd performs the actual directory creation, so make sure it is running:

systemctl is-active oddjobd

active

After Jane logs in once, check that her home directory exists:

ls -ld "/home/jane@lab.example"

The user needs write permission here if you expect uploads into the home directory.

For shared team directories outside $HOME, use group ownership on a dedicated path—similar to Samba shares for AD users without smbd.

Open the firewall for SSH

SFTP uses the same TCP port as SSH: port 22. If firewalld is enabled, allow the predefined SSH service:

sudo firewall-cmd --permanent --add-service=ssh

Reload firewalld so the rule takes effect:

sudo firewall-cmd --reload

Test normal SFTP first

Test a normal SFTP login before adding any Match or chroot rules. That way, if something fails later, you know the basic AD and SFTP setup was already working.

Because the AD username already contains @, pass it with -o User= so it is clear where the username ends and the hostname begins:

sftp -o User='jane@lab.example' vm1.lab.example

If you want to test directly from the RHEL server, connect to localhost:

sftp -o User='jane@lab.example' 127.0.0.1

At the sftp> prompt, print the working directory, upload a file, and list:

sftp> pwd
Remote working directory: /home/jane@lab.example
sftp> put /etc/hostname sftp-ad-test.txt
sftp> ls
sftp-ad-test.txt

If the upload succeeds, the full path is working: SSH accepted the user, the account passed the AD/SSSD checks, and the user can write to the destination directory.

Windows admins often use WinSCP with username jane@lab.example and the server hostname vm1.lab.example.

Optional: make an AD group SFTP-only

Match Group applies special SSH settings to members of that group. In this example, members of network-admins@lab.example are forced into SFTP instead of getting a shell. It does not stop other users from using SFTP unless you add separate access restrictions.

SSH must use the same group name that Linux sees. Check it before creating the Match Group rule:

getent group 'network-admins@lab.example'

Example drop-in /etc/ssh/sshd_config.d/sftp-only-group.conf:

Match Group network-admins@lab.example
    ForceCommand internal-sftp
    DisableForwarding yes

Validate syntax before reload:

sudo sshd -t

Keep your current admin SSH session open while you test a new Match block so you can revert a mistake that locks you out.

If sshd -t returns no errors, reload SSH:

sudo systemctl reload sshd

Optional: chroot SFTP-only users

Chroot is advanced. Use the normal home workflow above first.

OpenSSH requires the chroot path and every parent component to be root-owned and not writable by the user. Because the user cannot own or modify the chroot directory itself, create a writable subdirectory such as upload inside it.

Example layout for one AD user:

sudo mkdir -p "/srv/sftp/jane@lab.example/upload"

The chroot directory itself must be root-owned with mode 755; only the upload child is writable by the AD user:

sudo chown root:root "/srv/sftp/jane@lab.example"
sudo chmod 755 "/srv/sftp/jane@lab.example"
sudo chown 'jane@lab.example':'domain users@lab.example' "/srv/sftp/jane@lab.example/upload"

Now apply the chroot only to Jane (drop-in or main sshd config):

Match User jane@lab.example
    ChrootDirectory /srv/sftp/%u
    ForceCommand internal-sftp
    DisableForwarding yes

Run sudo sshd -t, then sudo systemctl reload sshd. Test SFTP from a second session before you close your admin connection.

If you want to chroot an entire AD group, first verify the group name with getent group. Each user still needs a root-owned chroot directory and a separate writable directory inside it.

Troubleshooting

Summary

Once RHEL can already authenticate AD users through SSSD, SFTP usually needs very little extra setup. OpenSSH handles the file-transfer session, while PAM and SSSD continue to handle AD password authentication.

Start with a normal SFTP login to the user’s home directory. Add Match, SFTP-only restrictions, or chroot directories only when your use case actually needs them.

Use vsftpd with SSSD only when a legacy client still requires FTP. Use Samba when the workload is SMB from Windows, not SFTP.

References

• Red Hat Enterprise Linux 10 — Securing SSH
• OpenSSH SFTP manual