Troubleshooting¶

Fixes for the problems you are most likely to hit with OpenSSH SFTP Drop Box. Each entry gives the symptom, the usual cause, and what to do.

The client cannot connect, or reaches the wrong SSH service¶

Cause: the SFTP service is on port 2222, not 22, and listens on 127.0.0.1 only. Port 22 is the instance's own SSH service, which SFTP users cannot sign in to.

Fix: always pass -P 2222 to sftp. To connect from other hosts, add a ListenAddress and open the security group, as described in Accept connections from your network.

`Permission denied (publickey)`¶

Cause: the client offered a key that is not the user's authorized key, or the client cannot read its own private key.

Fix: check that the client uses the right key with -o IdentitiesOnly=yes -o IdentityFile=<key>. On the instance, the transfer key is readable only by root, so run sftp with sudo. To give a user a new key, run the helper again, as described in Replace a user's key.

Uploads fail with `Permission denied`¶

Cause: the user is writing outside incoming/. The top of each user's folder is owned by root and is read-only for the user.

Fix: upload into incoming/, where every session starts.

The SFTP service does not start¶

Cause: usually a mistake in sshd_config, or a first boot failure.

Fix: check the configuration and read the logs:

sudo sshd -t -f /opt/sushi/etc/sftp/sshd_config
systemctl status sushi-sftp-firstboot sushi-sftp --no-pager
sudo journalctl -b -u sushi-sftp-firstboot -u sushi-sftp --no-pager

First boot fails because a `transfer` account already exists¶

Cause: an account called transfer existed before first boot and is not a managed SFTP user, so first boot will not take it over.

Fix: keep the existing account as it is. Do not delete it or change it to suit the SFTP service. Use a clean instance instead.

First boot reports an invalid or mismatched key¶

Cause: a key file under /var/lib/sushi-sftp/customer/ or /var/lib/sushi-sftp/hostkeys/ is missing, empty, a link, or does not match its pair.

Fix: restore the original key pair from your backup, with the private key owned by root:root and mode 0600, then retry:

sudo systemctl restart sushi-sftp-firstboot sushi-sftp

Do not delete the firstboot-complete marker to force new keys. That would change the server's identity and lock out your clients.