A transfer account that can wander the entire server is an accident waiting for a curious user. The jail fixes it - and the number one reason the jail refuses login is a folder ownership rule almost nobody expects.
Without restriction, SFTP opens at the user's home folder but nothing stops them browsing up into /etc, other homes and anywhere the account can read. A chroot changes what the user sees as the root of the world: one folder becomes their entire filesystem. Ubuntu's SSH server enforces it strictly, and the strictness has a famous trap that this guide walks around deliberately.
SSH refuses a chroot login unless every folder in the jail path is owned by root and is not writable by anyone else. Not the user. Not the group. Root only. The failure looks like this in /var/log/auth.log: bad ownership or modes for chroot directory - and the user simply gets disconnected with no explanation on their side.
This feels backwards until you see the reason: if the jailed user could rename or replace a folder on the path, the jail could be escaped. So the design below keeps the jail folder itself root-owned and read-only for the user, and puts one writable subfolder inside it.
Create the group, the folders and the test user:
sudo groupadd sftpuserssudo mkdir -p /srv/sftp/ravi/uploadssudo chown root:root /srv/sftp and sudo chown root:root /srv/sftp/ravi, with sudo chmod 755 on bothsudo chown ravi:sftpusers /srv/sftp/ravi/uploadssudo adduser ravi if the account is new, then sudo usermod -aG sftpusers raviRead that layout once more: ravi can enter and see /srv/sftp/ravi but cannot write to it; everything he uploads lands in uploads, the one folder he owns.
/etc/ssh/sshd_config to Subsystem sftp internal-sftp - the internal server is what makes the jail work without extra files inside itsudo sshd -t to check the config for typing errors before restarting - a broken config plus a restart is how admins lock themselves outsudo systemctl restart sshThe ForceCommand internal-sftp line means members of the group get a file transfer session and nothing else - no shell, no terminal, no commands - even if they try with a normal SSH client. AllowTcpForwarding no closes the side door of using your server as a tunnel.
Ordinary admin accounts are untouched because the block matches only the sftpusers group. Your own login keeps its full shell, which is exactly how it should be: jails are for transfer accounts, not for the person holding the keys.
See the whole Ubuntu SFTP setup done live, with the exact clicks and commands, in the Technical Anshu video.
Watch Full VideoAlmost always the ownership rule: some folder in the jail path is owned by the user or writable by the group. Check /var/log/auth.log for the bad ownership message, then make every path component root-owned with 755 permissions and give the user a writable subfolder inside.
Yes. Files you copy into their uploads folder, owned by them or readable by them, download normally. The jail limits where they can go, not what they can do inside their own folder.
Yes, combined with ForceCommand internal-sftp the account gets file transfer only. A shell login attempt with the same account simply fails, even with the correct password or key.