SFTP and file access
Plain FTP sends the password in clear text and needs a second connection for data. There is no configuration that fixes either.
Use SFTP
It runs over SSH, so you already have it: one port, encrypted, and the same authentication you already trust. Nothing to install.
FTPS exists and is better than FTP, but it keeps the two-connection design and the firewall headaches that come with it. If someone insists on FTP, the question worth asking is what they are actually trying to do.
A locked-down SFTP account
In /etc/ssh/sshd_config:
Match Group sftponly
ChrootDirectory /srv/sftp/%u
ForceCommand internal-sftp
AllowTcpForwarding no
X11Forwarding no
PermitTunnel no
Then create the user with no shell:
useradd -g sftponly -s /usr/sbin/nologin -d /srv/sftp/jan jan
That account can read and write files and do nothing else — no shell, no port forwarding, no tunnel. See SSH tunnels for why those three matter.
The chroot ownership rule that catches everyone
The chroot directory itself must be owned by root and not writable by the user. Otherwise sshd refuses the connection with an unhelpful message.
chown root:root /srv/sftp/jan && chmod 755 /srv/sftp/jan
Then give them a writable subdirectory inside it:
mkdir /srv/sftp/jan/upload && chown jan:sftponly /srv/sftp/jan/upload
If a connection drops immediately after authentication, this is almost always why.
Keys, not passwords
The same argument as everywhere else: a key cannot be guessed, and you can revoke
one without changing anything else. Put the customer's public key in their
authorized_keys and keep PasswordAuthentication no globally
— see securing a new server.
If a customer genuinely cannot manage a key, a per-user password exception inside
the Match block is possible. Do it knowingly, and pair it with
fail2ban.
Watch what lands there
An upload directory that the web server also serves is how a web shell gets
executed. Either keep uploads outside the web root, or mount that path
noexec and make sure your web server will not run anything from it. See
permissions and ownership and
scanning for malware.
For bulk transfers, use rsync
SFTP is fine for a handful of files and poor for a large tree: no delta transfer, no
resume worth the name. Over the same SSH connection,
rsync does the job properly — and an account
restricted to internal-sftp cannot run it, so decide which you are
offering.
Still stuck? Mail support@novogara.com — an engineer answers, at any hour. Back to the knowledge base