Ask most teams whether their SFTP server is logged and the answer is yes. Ask which files a specific partner downloaded last March and the answer changes.

Both are true, and the gap between them is a configuration default almost nobody has looked at.

What does SFTP actually log?

At stock OpenSSH settings, sshd records the connection, not the transfer.

You get authentication events, which key or password method succeeded, the source address, and session open and close. That is enough to answer who connected, from where, and when.

File operations are handled by the SFTP subsystem, and at default settings those are not individually recorded. The daemon knows a session happened. It does not write down that the session pulled twelve files out of a directory.

This is not a bug. OpenSSH's logging was built as diagnostic output for operators, not as an evidentiary record for auditors. It does the job it was designed for.

The one-line fix

Raising the subsystem log level produces per-file entries for opens, closes, renames, and removes. In sshd_config:

Subsystem sftp internal-sftp -l VERBOSE

Output then looks roughly like this:

sshd[27990]: Accepted publickey for robtest from 71.179.98.86 port 56155
sshd[27990]: session opened for local user robtest [postauth]
sshd[27990]: opendir "/local" [postauth]
sshd[27990]: open "/local/Installer.pkg" flags WRITE,CREATE,TRUNCATE [postauth]
sshd[27990]: close "/local/Installer.pkg" [postauth]

That is a genuine improvement and worth making on any OpenSSH host that can take it. If you do nothing else after reading this, do that.

Three caveats, in increasing order of annoyance.

Chroot breaks it. If partners are chrooted, which they usually are, logging fails unless a /dev/log socket exists inside each chroot or you switch to internal-sftp and log through the privileged monitor. Red Hat's guidance covers the mechanics.

Appliances may not allow it at all. F5 BIG-IP, for example, does not log individual SFTP commands or file operations during a session, and modifying the SFTP subsystem in sshd_config throws an error because the subsystem is already defined. Changes there are also not persistent across reboots.

Some platforms need a different mechanism entirely. Solaris audits SFTP through the ft audit class rather than through sshd verbosity.

Is a verbose log the same as an audit trail?

No, and this is the part worth sitting with.

Turning on -l VERBOSE gets you a record of file operations. It does not get you a record that survives being questioned.

What is missing from SFTP audit logs?

Four things, even with verbose logging on.

Integrity. The log is a text file on the same host as the service. Anyone with root can edit it, and nothing in the format would reveal that they had. An auditor asking whether the record is complete has only your word.

Content identity. You get a filename and a path. You do not get a hash. If a partner claims the file you sent them was different from the file you say you sent, the log cannot settle it. The filename matched. That is all it establishes.

Human identity. The log records the account. If three people at your billing vendor share one service credential, which is common, the log says the credential was used. It does not say who used it.

Downstream access. The log ends at your boundary. It records that the file left. Everything after that, who opened it on the other side, whether it was copied, when it was deleted, is invisible to you and always will be.

Which of those can you actually fix?

Three of the four, on your own infrastructure.

Integrity: ship logs off-host immediately. A log that lives only where the service runs is a log the service's compromise takes with it. Forwarding to storage under separate control is the single largest improvement available for free, and it is what most audit questions actually turn on. If the record can be altered without detection, its evidentiary value is thin regardless of how detailed it is.

Content identity: hash on the way out. Compute and store a digest at send time and "was this the file we sent" becomes checkable rather than arguable. Small amount of work in a transfer script, closes a whole category of dispute. This one matters more in disagreements than in audits.

Human identity: kill shared service accounts where you can. Not always possible with partners who have their own conventions, but every one you convert to per-person credentials turns a log line from an account name into an answer. Shared credentials are not against a rule. They just make "who accessed this" unanswerable.

Downstream access, you cannot fix at the SFTP layer. No configuration on your server observes what happens on someone else's machine. That requires the exchange itself to carry the record, which is a different architecture rather than a different setting.

Does a file transfer platform solve this?

Partly, and it is worth being specific about which parts.

We do not replace your logging stack. If your problem is centralizing and retaining logs across a fleet, that is a SIEM and a log pipeline, and those are mature products. We are not one.

What we affect is the last item on that list. Every exchange produces a structured, append-only, tamper-evident audit event exported to storage you control, and access is identity-bound rather than tied to a shared service credential. So the record is not a text file on the host that produced it, and "who accessed this" resolves to a person rather than an account.

That is a narrower claim than solving audit logging. It is the part where a session log structurally cannot help, because the event it would need to record happens somewhere your server cannot see.

More on audit evidence and identity-bound access. Related: replacing SSH keys with short-lived certificates. For healthcare specifically, HIPAA-compliant file sharing.

The short version

Your SFTP server is logged. It is logging the wrong thing by default, and the fix is one line in sshd_config that takes about a minute.

After that line, you have a detailed record of file operations that lives on the host that produced it, identifies accounts rather than people, and stops at your network boundary. Whether that is sufficient depends entirely on which question you expect to be asked.

Worth finding out before someone asks it.

Request a demo

Sources

• EnterpriseDT, SFTP Audit Logs for Compliance: What Auditors Actually Want
• Red Hat Customer Portal, Logging sftp commands
• F5, K000151196: Logging SFTP commands
• Oracle, How to Audit FTP and SFTP File Transfers
• MyWorkDrive, SFTP Vulnerabilities: 8 Security Risks and How to Fix Them