What is SFTP and how does it work

Every time you upload a file to your web server, that file travels across the internet. If the connection is not encrypted, everything in that transfer is visible to anyone who can observe the network path between you and the server – your username, your password, and every byte of the file itself, all in plaintext.

This was how file transfers worked for decades. FTP, the protocol most people used to upload files to web servers, was designed in an era when network security was not a practical concern. It transmitted credentials in cleartext and required multiple firewall-unfriendly connections to move a single file. It worked, but it was never safe.

SFTP replaced FTP by taking a fundamentally different approach. Instead of patching encryption onto an insecure protocol, SFTP runs entirely inside an SSH connection – the same encrypted channel you use for terminal access to a server. One connection, one port, everything encrypted from the first byte. If your hosting provider gives you SSH access, SFTP comes with it automatically. No additional setup, no separate credentials, no extra software to install.

This article covers what SFTP is, how the protocol works at each stage of a connection, how it compares to FTP and FTPS, and how it fits into a modern hosting environment. If you are looking for the actual commands, see the SFTP commands reference guide.

SFTP vs FTP vs FTPS

These three protocols are frequently confused. They sound similar but work very differently.

FTP (File Transfer Protocol)

FTP is the original file transfer protocol, standardized in 1985 but based on work from the early 1970s. It transmits everything – usernames, passwords, and file contents – in plaintext. Anyone on the network path between you and the server can read the data. A compromised router, a malicious Wi-Fi hotspot, or even an ISP with packet inspection can capture your credentials and file contents without any effort.

FTP also uses two separate connections: a control connection on port 21 for sending commands, and a data connection on a dynamically negotiated port for the actual file transfer. This two-connection model creates persistent operational problems:

• Active mode requires the server to open a connection back to the client on a port the client specifies. This fails behind NAT because the server cannot reach the client’s internal IP address.
• Passive mode has the server open a high-numbered port and tell the client to connect to it. This requires a range of ports (often thousands) to be open on the server’s firewall.
• Firewalls and NAT gateways need FTP-aware connection tracking modules to dynamically open the correct ports. When these modules are absent or misconfigured, transfers fail silently or hang.

FTP has no place on a modern web server. Transmitting credentials in plaintext over the internet is not a preference question – it is a security failure. If your hosting provider only offers plain FTP, that tells you something about how seriously they take infrastructure security.

FTPS (FTP Secure)

FTPS adds TLS encryption to FTP, the same encryption layer that HTTPS uses. It is sometimes called FTP-SSL. There are two modes:

Explicit FTPS: The connection starts as plain FTP on port 21 and upgrades to TLS when the client sends an AUTH TLS command. This means the initial connection (including the command to start encryption) is unencrypted.

Implicit FTPS: The connection starts as TLS immediately, typically on port 990. More secure than explicit mode because there is no unencrypted phase, but uses a non-standard port.

FTPS solves the plaintext problem – credentials and file data are encrypted in transit. But it inherits every architectural problem from FTP. It still uses two connections. It still needs passive port ranges. It still breaks behind firewalls. In fact, adding TLS makes the firewall problem worse: the connection tracking modules that make FTP work through firewalls cannot inspect encrypted traffic, so they cannot dynamically open the correct data ports. You end up having to pre-open wide port ranges in the firewall, which weakens your security posture.

FTPS also requires a valid TLS certificate on the server side, adding certificate management (issuance, renewal, chain validation) as another operational burden. And client support for FTPS is less consistent than for SFTP – some clients handle explicit mode, some handle implicit, some handle both, and certificate validation errors are a common source of connection failures.

FTPS works, and it is genuinely secure in transit. But it carries unnecessary complexity for a problem that SFTP solves more cleanly.

SFTP (SSH File Transfer Protocol)

SFTP shares nothing with FTP except the words “file transfer.” It is a completely different protocol that runs as a subsystem of SSH.

• Single connection on port 22. Everything – authentication, commands, and data – flows over one encrypted SSH connection. No firewall issues, no dynamic port negotiation, no passive mode.
• Full encryption from the first byte. The SSH layer encrypts everything before any data moves. There is no plaintext phase and no upgrade mechanism that could be intercepted.
• Uses SSH authentication. The same password or SSH key you use for SSH terminal access works for SFTP. No separate credentials to manage, no separate user database.
• Built into OpenSSH. If a server runs OpenSSH (which virtually every Linux server does), SFTP is available immediately with no additional configuration. The SSH daemon includes the SFTP subsystem by default.
• No certificate management. SSH uses host keys that are generated automatically when the server is installed. There is no certificate authority, no chain of trust to configure, and no renewal cycle to manage.

For web hosting, SFTP is the correct choice in virtually every situation.

Comparison summary

How SFTP works

When you connect to an SFTP server, a precise sequence of events establishes a secure channel before any file data moves. Understanding these steps helps when troubleshooting connection failures and explains why SFTP is fundamentally more secure than FTP.

1. TCP connection

Your SFTP client opens a TCP connection to the server on port 22 (or whatever port SSH is configured on). This is a standard TCP three-way handshake – nothing encrypted yet, just establishing a reliable byte stream between the two machines.

2. SSH protocol negotiation

The client and server exchange their SSH version strings (e.g., SSH-2.0-OpenSSH_9.6 ). Modern systems use SSH-2, which has been the standard since 2006. SSH-1 had structural vulnerabilities and should never be used. If either side only supports SSH-1, the connection should be refused.

3. Key exchange

This is the cryptographic foundation of the entire session. The client and server negotiate a shared secret using a key exchange algorithm – typically Elliptic Curve Diffie-Hellman (ECDH) or Curve25519. The mathematics of this exchange are designed so that both sides can independently compute the same shared secret without ever transmitting it. Even if an attacker records the entire key exchange, they cannot derive the shared secret without one of the private keys.

During this step, the two sides also agree on:

• The encryption cipher for the session (typically AES-256-GCM or ChaCha20-Poly1305)
• The message authentication code (MAC) for verifying data integrity (ensuring no one has tampered with packets in transit)
• The compression algorithm (usually none, since modern connections are fast enough that compression overhead is not worth it)

The shared secret is used to derive symmetric encryption keys. From this point forward, every byte transmitted in either direction is encrypted.

4. Server authentication

The server presents its host key – a cryptographic identity that uniquely identifies the server. Your client checks this key against its known hosts file ( ~/.ssh/known_hosts on Linux and Mac, or PuTTY’s registry on Windows).

• First connection: The key is new. Your client displays the key fingerprint and asks you to verify and accept it. Once accepted, the key is stored locally.
• Subsequent connections: The client checks the stored key against what the server presents. If they match, the connection proceeds silently. If they do not match, the client raises a warning.

A host key mismatch is a serious signal. It can mean the server was legitimately rebuilt or reconfigured, but it can also mean someone is intercepting your connection and presenting their own server (a man-in-the-middle attack). Do not ignore host key warnings. Verify with your hosting provider if the key changes unexpectedly.

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

This warning exists to protect you. Treat it as a real security event until you have confirmed the change was legitimate.

5. User authentication

With the encrypted channel established, you now prove your identity. SFTP supports the same authentication methods as SSH:

Password authentication. You provide your username and password. The password travels through the already-encrypted SSH channel – it is never exposed in plaintext on the network. The server checks the password against its authentication database.

Public key authentication. Your client proves it holds a private key that corresponds to a public key the server has on file. The server sends a challenge, your client signs it with the private key, and the server verifies the signature with the public key. The private key never leaves your machine and is never transmitted. This is the stronger option – there is no password to guess, phish, or steal. See the SSH key authentication section below for details.

6. SFTP subsystem request

Once authenticated, the SSH client requests the SFTP subsystem. The server starts its internal SFTP handler (typically internal-sftp , which is built into the SSH daemon). This handler runs within the SSH session and processes all file transfer commands.

The subsystem model is why SFTP requires no additional server software. The SSH daemon already includes the SFTP handler. There is no separate service to install, configure, or maintain.

7. File operations

The SFTP protocol uses a binary request-response format. Your client translates human-readable commands ( put , get , ls , chmod ) into binary SFTP packets and sends them through the encrypted SSH channel.

Every operation is a request-response pair:

• File upload: The client sends an OPEN request, receives a file handle, sends WRITE requests with chunks of file data, then sends CLOSE.
• File download: The client sends an OPEN request, receives a handle, sends READ requests, receives file data in response, then sends CLOSE.
• Directory listing: The client sends OPENDIR, receives a handle, sends READDIR requests, receives directory entries.

All of these exchanges happen over the single SSH connection. There is no separate data channel and no port negotiation. This is why SFTP never has the firewall and NAT issues that plague FTP.

SFTP port number

SFTP uses port 22 – the same port as SSH. This is not a coincidence. SFTP runs inside SSH, so it uses SSH’s port. There is no separate “SFTP port.”

Some servers run SSH on a non-standard port to reduce noise from automated scanning in server logs. In that case, set your SFTP client to the same non-standard port. On Hostney, each account’s SSH port is shown in the control panel under Terminal Access. An orchestrator on the server handles routing each connection to the correct account’s container.

When configuring an SFTP client, use the capital -P flag for port (not lowercase -p , which preserves timestamps):

sftp -P 12345 username@hostname

Do not confuse SFTP’s port with:

• FTP port 21 (control connection for plain FTP)
• FTPS port 990 (implicit FTPS)
• FTPS port 21 (explicit FTPS, same as FTP but upgrades to TLS)

What SFTP encrypts

The SSH layer encrypts the entire SFTP session:

• Your credentials. Whether you authenticate with a password or an SSH key challenge, the authentication exchange is encrypted.
• All commands. Every instruction you send – list directory, open file, rename, delete, change permissions – is encrypted.
• All file contents. Every byte of every file you upload or download is encrypted in transit.
• All server responses. Directory listings, file metadata, error messages – everything the server sends back is encrypted.
• Metadata. File names, paths, sizes, timestamps, and permissions in directory listings are all encrypted.

A network observer sees only that an SSH connection exists between your IP and the server’s IP on port 22. They can observe the volume of data transferred and the timing of the connection. They cannot see what files you are transferring, what commands you are running, or what your credentials are.

What SFTP does not encrypt

SFTP protects data in transit. It does not protect data at rest or the endpoints themselves.

Data on disk. Once a file is uploaded to the server, it sits on disk unencrypted (unless the server uses full-disk encryption or per-file encryption, which is a separate layer). If the server is compromised, uploaded files are exposed regardless of how securely they were transferred.

The endpoints. If your local machine has a keylogger or malware, the attacker can capture files and credentials before they reach the SSH encryption layer. If the server is compromised at the OS level, the attacker has access to files after they are decrypted. Transport encryption protects the wire between the endpoints, not the endpoints themselves.

Connection metadata. An observer can see that your IP connected to the server’s IP on port 22. They can estimate the amount of data transferred based on packet sizes. They cannot see the contents.

This is the same trust model as HTTPS/TLS. The channel is secure, but the security of the data ultimately depends on the security of the machines at each end.

SFTP authentication methods

Password authentication

The simplest method. You provide your account password when connecting. The password is transmitted through the encrypted SSH channel, so it is not exposed on the network.

The weakness of password authentication is not in SFTP’s handling of the password – it is in the password itself. Weak passwords can be guessed through brute force. Passwords can be phished. Passwords can be reused across services and compromised in a data breach elsewhere. And automated bots constantly probe SSH ports with common username/password combinations – the same credential stuffing attacks that target WordPress login pages also target SSH.

Password authentication works, but for any server you access regularly, SSH key authentication is the better option.

SSH key authentication

A key pair consists of two mathematically related keys:

Private key. Stored on your local machine, never shared with anyone. This is the credential – whoever has this file can authenticate as you. Guard it the same way you guard a password, except it is much harder to steal because it is a file on your machine rather than something you type.

Public key. Stored on the server in ~/.ssh/authorized_keys . Can be shared freely with anyone. The public key alone cannot be used to authenticate – it can only verify that someone has the corresponding private key.

When you connect, SSH uses a challenge-response protocol:

1. The server generates a random challenge and encrypts it with your public key.
2. Your client decrypts the challenge with your private key and sends back the result.
3. The server verifies the result matches the original challenge.

The private key never leaves your machine and is never transmitted over the network. Even if an attacker intercepts the entire authentication exchange, they cannot extract the private key from it.

This is stronger than password authentication for several reasons:

• No shared secret. The server only has your public key, which is not sensitive. Even if the server is compromised, your private key is not exposed.
• No brute force. There is no password to guess. A 256-bit Ed25519 key or 4096-bit RSA key is computationally infeasible to crack.
• No phishing. You cannot be tricked into typing your key into a fake login page because you never type it anywhere.
• Automation friendly. Scripts and automated processes can authenticate without storing passwords in configuration files or environment variables.

Key pairs can use different algorithms:

• Ed25519. The modern recommended choice. Fast, secure, compact keys. Use this unless you have a specific reason not to.
• ECDSA. Also secure and widely supported. Slightly more compatible with older systems than Ed25519.
• RSA. The traditional choice. A 4096-bit RSA key is secure but generates larger keys and is slower than Ed25519. Still widely used because of universal compatibility.

To generate an Ed25519 key pair:

ssh-keygen -t ed25519 -C "your-email@example.com"

This creates ~/.ssh/id_ed25519 (private key) and ~/.ssh/id_ed25519.pub (public key). Add the public key to your server’s ~/.ssh/authorized_keys file, or upload it through your hosting control panel.

On Hostney, SSH key management is built into the control panel. You can generate a new key pair or import an existing public key, and optionally restrict the key to specific IP addresses for additional security. See the SSH keys guide for setup instructions.

IP-restricted keys

Some environments support restricting an SSH key so it only works from specific IP addresses. The server adds a from="x.x.x.x" prefix to the public key entry in authorized_keys . Even if someone obtains your private key, they cannot use it from a different IP address.

This is particularly useful for automated systems that always connect from a known IP and for environments where defense in depth is a requirement.

SFTP and SSL are not the same thing

SFTP and SSL (more accurately TLS) both provide encryption, but they protect different things at different layers.

SSL/TLS encrypts HTTP traffic between a web browser and a web server. It is what makes HTTPS work. When a visitor loads your website, TLS encrypts the page content, form submissions, cookies, and API responses in transit. TLS uses certificates issued by Certificate Authorities (CAs) to verify the server’s identity. These certificates must be obtained, installed, and renewed – see How to install an SSL certificate for the full process.

SFTP encrypts file transfer sessions between an SFTP client and an SSH server. It uses SSH’s own encryption and authentication system, which is independent of TLS. There are no Certificate Authority certificates involved. SSH uses host keys that are generated on the server when the SSH daemon is installed.

Both encrypt data in transit between two endpoints. Neither encrypts data at rest on the server. They serve different purposes and protect different channels:

• TLS protects your visitors’ traffic to your website
• SSH/SFTP protects your administrative access for managing files on the server

A properly secured web server uses both. TLS for the public-facing web traffic, SSH/SFTP for the administrative back channel. They are complementary, not alternatives.

Why use SFTP for web hosting

Secure file transfers

Every file you transfer to your web server – PHP files, theme uploads, configuration changes, images – goes over an encrypted connection. If you are on public Wi-Fi, a hotel network, or any untrusted network, there is no risk of your files being intercepted or your credentials being stolen in transit.

Single port, firewall friendly

Port 22 is a single, well-known port. Firewalls are straightforward to configure: allow outbound TCP to port 22 and SFTP works. No port ranges, no passive mode configuration, no connection tracking modules. FTP’s dynamic port negotiation causes constant firewall issues that SFTP eliminates entirely.

No extra configuration

If SSH is enabled on your server, SFTP works immediately. The SSH daemon includes the SFTP subsystem. There is no separate server to install, no configuration file to edit, and no additional service to monitor.

Same credentials as SSH

One set of credentials for both SSH terminal access and SFTP file transfers. No separate SFTP password to remember or rotate. If you use SSH key authentication, the same key works for both. This reduces credential management overhead and eliminates the risk of having a strong SSH password but a weak FTP password (a common misconfiguration on servers that run both).

Reliable large file transfers

SFTP handles large file transfers reliably over a single persistent connection. The SSH layer manages the connection, retransmits lost packets (via TCP), and the protocol supports appending to partial downloads for resuming interrupted transfers. For uploading large files that exceed your web server’s HTTP upload limit, SFTP bypasses the web server entirely – the transfer goes directly to the filesystem.

Direct filesystem access

SFTP gives you access to any file your user account has permissions for, not just files that a web-based file manager exposes. You can access server configuration files, .htaccess , wp-config.php , error logs, and files outside the web root. This matters most when something is broken – if a bad plugin or a misconfigured .htaccess makes your WordPress admin inaccessible, SFTP still works because it does not depend on WordPress being functional.

This is also why security best practices recommend disabling the WordPress file editor in the admin dashboard. If an attacker gains admin access, the built-in editor lets them modify PHP files through the browser. With the editor disabled, file changes require SFTP or SSH access – a separate authentication barrier.

SFTP in a containerized hosting environment

On traditional shared hosting, all user accounts run on the same operating system instance. Every SFTP session accesses the same filesystem. Isolation depends entirely on Unix file permissions – if permissions are misconfigured on any account, other accounts can potentially read or write to those files. A compromised account can attempt to traverse the filesystem and access files belonging to other users.

Containerized hosting eliminates this class of vulnerability. Each account runs in its own container with its own filesystem namespace. Your SFTP session cannot see other accounts’ files because they do not exist in your container’s view of the filesystem. There is no permission misconfiguration that can bridge this gap – the isolation is enforced at the kernel level, below what any user-space process can influence.

On Hostney, each account’s SSH and SFTP access runs inside a dedicated container. The SFTP subsystem is built into the container’s SSH server ( internal-sftp ), so file transfers happen entirely within the container’s isolated filesystem. Your session starts in your home directory, which contains your website files. You cannot navigate above it. You cannot access other accounts. A compromised session in one container cannot affect any other container on the same server.

The container also enforces resource boundaries. CPU and memory limits are set per account, so an SFTP session transferring large files on one account does not degrade performance for other accounts on the same physical server.

For a detailed look at how container isolation works and why it provides stronger guarantees than traditional shared hosting approaches, see How Hostney isolates websites with containers.

SFTP access on Hostney

On Hostney, SFTP access is included with every account. No additional packages, no add-on fees, no configuration needed.

Connect using:

• Host: your server hostname (shown in the control panel)
• Port: your assigned SSH port (shown under Terminal Access in the control panel)
• Username: your account username
• Authentication: SSH key (recommended) or password

An orchestrator on the server routes your connection to the correct container automatically. You do not need to know or configure anything about the underlying infrastructure – just use the hostname, port, and credentials from the control panel.

Your SFTP session starts in your home directory, which contains your website files. From there you can navigate to your web root, upload files, fix permissions, and manage your site’s filesystem directly.

For GUI access, any SFTP client works – WinSCP, FileZilla, Cyberduck, or the built-in terminal on Mac and Linux. For command-line usage, see SFTP commands: a complete reference guide for every command you need.

Security best practices

SFTP is inherently more secure than FTP, but the overall security of your file transfer workflow depends on how you use it.

Use SSH keys instead of passwords. Keys are cryptographically stronger, cannot be brute forced, and do not require you to transmit a secret. If your hosting provider supports SSH key authentication, set it up. It takes minutes and eliminates an entire class of attack.

Do not ignore host key warnings. A changed host key can mean the server was rebuilt (legitimate) or that someone is intercepting your connection (not legitimate). Verify with your hosting provider before accepting a changed key.

Keep your SFTP client updated. SFTP clients implement the SSH protocol, which evolves to deprecate weak algorithms and address newly discovered vulnerabilities. Use a maintained client (OpenSSH, WinSCP, FileZilla) and keep it current.

Protect your private key. Your SSH private key is equivalent to a master password. Do not email it, paste it into chat, commit it to a Git repository, or store it on shared drives. If you suspect it has been compromised, generate a new key pair and remove the old public key from all servers.

Use IP restrictions where possible. If you always connect from the same IP addresses, restricting your SSH key to those IPs adds a layer of protection even if the key is compromised.

Be aware of what you transfer. SFTP encrypts the channel, not the files on disk. If you upload a file containing database credentials, API keys, or private keys, those secrets exist in plaintext on the server’s filesystem. Server-side file permissions and container isolation protect them from there.

Summary

SFTP is a file transfer protocol that runs inside an encrypted SSH connection. It replaces FTP by providing the same file management capabilities – upload, download, rename, delete, set permissions – over a single encrypted connection on a single port, without FTP’s architectural complexity or security weaknesses.

The protocol establishes an SSH connection first (key exchange, server verification, user authentication, encryption activation) and then runs the SFTP subsystem inside that encrypted channel. All commands and data travel through the encrypted connection. There is no plaintext exposure, no secondary data channel, and no port range to manage.

For web hosting, SFTP is the standard way to manage server files. It works when WordPress is broken, bypasses HTTP upload limits, handles bulk file operations efficiently, and provides direct access to files that browser-based tools cannot reach. Combined with SSH key authentication and proper server isolation, it is both secure and practical for day-to-day site management.

For the full command reference, see SFTP commands: a complete reference guide.