comparison Linux & administration
SSH vs SFTP
Compare SSH remote command sessions with SFTP file transfers carried over SSH, including their security limits.
What it means
SSH (Secure Shell) is a protocol family for protected remote access, authentication and encrypted channels. The OpenSSH ssh client commonly opens a remote shell or runs an authorized command. SFTP (SSH File Transfer Protocol) is a separate file-transfer protocol usually carried inside an SSH connection. It can list, upload, download and manage remote files within the permissions granted to that account. SSH manual SFTP manual
Despite its name, SFTP is not ordinary, unencrypted FTP, and is not FTPS (FTP protected by TLS). FTP-over-TLS distinction SSH access and SFTP access can use the same account and SSH transport, but a server can deliberately allow SFTP-only sessions without granting an interactive shell.
Try it
Simulation — test permission boundaries, not a real connection. Select a fictional account policy, host-trust and authentication conditions, then run one allowed command or file operation against the toy incoming path. No hostname, credentials, private key or terminal is connected to this scene.
Compare SSH and SFTP capabilities
Pass host identity, authentication and account-policy gates before performing an allowed operation.
Host identity answers “which server?”, authentication answers “which user?”, and authorization answers “which operation?”. Passing one gate does not imply the others.
| Item | State / result | Why it matters |
|---|---|---|
| Transport | SSH in both examples | SFTP is not FTP or FTPS. |
| Account policy | sftp-only | A transfer-capable account need not allow a shell. |
| Host identity | trusted | A mismatch stops before the operation. |
| Authentication | valid | No real secret is needed or accepted. |
| Private incoming | Empty | A local simulated file, not published content. |
| Production current | Unchanged | The model has no publication operation. |
No SSH session, file upload, shell execution, credentials or private keys.
About this model
SFTP uses SSH transport but an SFTP-only account can deny shell channels. The invented filesystem contains only a private incoming path; transferring bytes is not deployment. Real permissions, chroot, forwarding and auditing depend on server configuration.
Read the article’s primary sources for protocol rules and implementation-specific limits. This scene has no network access.
With an SFTP-only account, a shell status action is denied even when the encrypted transport and authentication conditions are satisfied. Listing or uploading to the permitted incoming location can succeed. Upload creates the synthetic package entry, not a production release. Try a host-key mismatch or failed authentication: execution stops before the requested file operation.
| Conditions and request | Local outcome | Boundary being demonstrated |
|---|---|---|
| Trusted host, authenticated SFTP-only user, list | Allowed toy listing | File-transfer authorization can exist without shell access |
| Same user, shell status action | Denied | SSH transport is not blanket command permission |
| Host key mismatches | Stop before operation | Peer identity is a separate gate from account authentication |
| Upload to permitted incoming path | Package entry appears | Transfer is not build, verification or publication |
| Traversal, protected destination or repeated overwrite | Stop | A bounded destination policy is still needed |
Reset clears the synthetic uploaded files, operation result and errors and restores the original SFTP-only account. Only the displayed path and predefined actions are supported. This is not a general SSH configuration or an assurance that all SFTP-only accounts have identical restrictions; administrators must explicitly configure each permitted capability. SSH SFTP Server-side restrictions
Shared security fundamentals
The SSH client should verify the server host key identity using a known trusted fingerprint or policy; a changed host key warning needs investigation, not a reflexive bypass. Authentication may use public keys or other allowed methods. A private key stays on the trusted client, protected by file permissions and preferably a passphrase or secure agent. Authentication and host keys
SFTP inherits encryption from SSH, not from the filename extension or graphical client. Encryption protects transport but cannot prevent an authorized user from uploading the wrong file, overwriting production, or exposing data through incorrect remote permissions. Host restrictions, least privilege, backups and checksums still matter. SFTP transport
Which should you choose?
Choose SFTP when the job is moving files: for example delivering a verified source package into a private incoming directory. Prefer SSH for approved status checks, controlled build commands or reviewing a server's logs. Do not assume SFTP clients can run server shell commands or that every SSH-enabled user is permitted to modify production files.
For websites built from static source, upload a complete candidate package, verify SHA256 on the destination, build and preview it outside the active web root, and switch a release only through the approved publisher. Do not overwrite a live site's HTML and hashed JavaScript piecemeal. The transport choice does not replace the release process.
In practice
Use SFTP for secure transfer and SSH for authorized remote execution, both with verified server identity and narrow permissions. For the files worth retaining, see Back up a small website. For serving several upstream services, see Reverse proxy. A verified transfer is not yet a verified deployment.
Key takeaways
SSH provides protected channels; shell and SFTP capabilities depend on authentication and authorization. Verify host identity, grant only the required actions and keep transfer separate from deployment. Do not resolve a warning by exposing a private key or automatically trusting a changed host key.
Frequently asked questions
Editorial questions, answered from the sources listed for this article.
Is SFTP the same as FTPS?
No. SFTP is a file-transfer protocol commonly carried inside SSH. FTPS is FTP protected with TLS. Their names and security transports are different, and clients or servers must support the intended protocol.
Does an SFTP-only account automatically allow a remote shell?
No. A server can restrict sessions to a file-transfer subsystem instead of a shell. Other capabilities, such as forwarding, also need their own server policy; a successful file transfer is not proof of unrestricted command access.
Sources & model boundaries
Primary references used for this explanation. The interactive example is an educational model, not a live check.
- OpenSSH ssh(1) manual
Description, authentication and host key verification. SSH remote login, command execution, authentication and host identity checking.
Checked .
- OpenSSH sftp(1) manual
Description, destination forms and interactive commands. Secure file transfers carried over the encrypted SSH transport.
Checked .
- OpenSSH sshd_config(5) manual
ForceCommand, Subsystem and forwarding restrictions. An internal-sftp restriction can replace shell access; forwarding and other capabilities require separate explicit policy.
Checked .
- RFC 4217 — Securing FTP with TLS
Abstract and protocol purpose only. FTP over TLS is distinct from SFTP over SSH. Historical TLS-version examples in this document are not current deployment guidance.
Checked .