Kingsfordweg 151, 1043GR Amsterdam, The Netherlands ● 24/7 support — support@novogara.com
Knowledge base

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