When a file goes missing or arrives somewhere it should not, opinions are cheap and logs are evidence. Ubuntu keeps the login records by default - this guide reads them, and adds the one setting that records the transfers themselves.
Two different questions get asked of an SFTP server: who connected, when, from where - and which files moved. The first is answered by logs Ubuntu already keeps. The second needs a small verbosity change, because by default the file transfer subsystem minds its own business quietly. Both are covered here, along with the limits of what a log can prove.
On Ubuntu, SSH writes to /var/log/auth.log, and the same events are in the journal:
sudo grep "sshd" /var/log/auth.log | tail -50 for the recent storysudo journalctl -u ssh --since today for a time-window viewsudo grep "for ravi" /var/log/auth.logEvery successful login records the account, the source address and the time. A key login additionally records which key was used when verbose login logging is on, which is why one person per account and per key matters - a shared account name in this log proves almost nothing.
A handful of failed attempts is a user mistyping. Hundreds of failures for accounts like root, admin or test, from addresses you do not recognise, is the internet knocking - normal for an exposed server, and the direct evidence behind the fail2ban guide in this series. Check the failures weekly even when nothing seems wrong; the week you stop looking is the week it matters.
To record file operations themselves, ask the SFTP subsystem to talk more:
/etc/ssh/sshd_config, change the subsystem or jailed ForceCommand line to include the level: ForceCommand internal-sftp -l VERBOSE in the Match block, or for non-jailed users Subsystem sftp /usr/lib/openssh/sftp-server -l VERBOSELogLevel VERBOSE so login lines record the key fingerprint usedsudo systemctl restart ssh/var/log/auth.log with the account, file name and actionOne honest wrinkle: for jailed users, the server process is cut off from the normal logging socket by the jail itself, so transfer lines from inside a jail need a logging socket created inside the jail folder - an rsyslog extra listener is the standard tool. Login records for jailed users still arrive normally, so you always keep the who-and-when even before adding that refinement.
Logs prove a connection happened, from an address, as an account, at a time, and with verbose logging, which files it touched. They do not prove which human sat at the keyboard - a stolen laptop with a saved key logs in as its owner. That is why logs are one control among several: unique accounts, keys with passphrases, and prompt removal of leavers. Keep the logs themselves somewhere they survive: they rotate, so for real history forward them or copy them off the server on a schedule, because the first thing a serious intruder edits is the record of the visit.
See the whole Ubuntu SFTP setup done live, with the exact clicks and commands, in the Technical Anshu video.
Watch Full VideoAlmost certainly not - you are being scanned, which is the background noise of the internet. Random names tried from foreign addresses is the classic pattern. It becomes urgent only if a real account succeeds from an address you do not recognise.
Because transfer logging is off by default. Add the verbose option to the SFTP subsystem or the jailed ForceCommand as shown in this guide, restart SSH, and file operations will start appearing in the auth log.
Ubuntu rotates them - typically a few weeks of auth logs are kept compressed on the machine. If you need months of history for audits, forward or archive them elsewhere; do not rely on the server alone.