FibaCloud
Skip to content
Ask a question

Press ESC to close

File Transfers with FTP, FTPS and SFTP

Protocol choice matters when transferring files: standard FTP does not encrypt passwords or file data. Use SFTP or FTPS with mandatory TLS, depending on what your server supports. SFTP is a separate protocol carried over SSH; FTPS adds TLS protection to FTP.

Prepare the account and connection details

This guide covers client uploads and downloads using an existing SFTP or FTPS account you are authorized to use. It does not install a server or change general access policies. A newly created cloud server does not necessarily include an FTP service or control-panel account.

Obtain the protocol, hostname, port, username, permitted destination directory and authentication method from the administrator. For SFTP, independently verify the SSH host fingerprint. For FTPS, verify the expected hostname and trusted certificate. Use a task-specific account limited to the required directory; file transfer should not require root access.

Back up existing site files before replacing them. Start with a small file in an empty test directory. Check quotas, available space and file-size limits.

Standard FTP does not encrypt control information or files. FTPS requires TLS for both control and data connections, with certificate verification. SFTP is a separate protocol over SSH, with host-key verification.
FTP / FTPS / SFTP compared Standard FTP does not encrypt control information or files. FTPS requires TLS for both control and data connections, with certificate verification. SFTP is a separate protocol over SSH, with host-key verification.
Text description of the illustration
  1. Standard FTP sends credentials and files in cleartext; do not send credentials.
  2. Require TLS for the FTPS control connection and private protection (PROT P) for data.
  3. For SFTP, compare the SSH host fingerprint through a trusted channel.
  4. Verify the server identity, account and destination before transfer; a port alone does not prove security.

Compare FTP, FTPS and SFTP

Protocol Transport protection Server identity Key requirement
FTP None in standard FTP No TLS/SSH verification Do not send passwords or private data.
FTPS TLS on control and data connections Certificate and hostname Reject unencrypted fallback and protect the data channel too.
SFTP SSH transport SSH host key Compare the first fingerprint through a trusted channel.

SFTP usually uses the SSH port. Explicit FTPS commonly begins on the FTP control port and opens additional data connections. A port number alone does not prove encryption. Use the protocol and port supplied by the administrator.

Connect with SFTP in FileZilla

Obtain FileZilla Client from its official source. Open File → Site Manager and create a new entry:

  1. Select SFTP — SSH File Transfer Protocol.
  2. Enter the verified hostname, port and assigned username.
  3. Select a password or key method accepted by the server. A private key stays on your device.
  4. Compare the first host key’s type and fingerprint with the trusted console/administrator record. Do not accept a mismatch.
  5. Confirm that the remote directory on the right is the intended destination, not another site with a similar name.

A certificate warning and an SSH host-key warning are different checks. Expecting a TLS certificate in SFTP or an SSH key in FTPS confuses the protocols.

If the server uses FTPS

Select FTP — File Transfer Protocol in Site Manager and set encryption to Require explicit FTP over TLS, after confirming server support. If the server requires a different FTPS mode, follow the administrator’s mode-specific port and client instructions.

Verify the certificate hostname, validity period and trusted chain. Do not bypass an unknown certificate or hostname mismatch with a permanent exception. Encrypting the control connection is not enough: file data needs TLS as well. In FTPS, PROT P requests private protection for the data connection. Check the client log for a protected data connection.

If directory listing works but transfers stall, have the administrator inspect the configured passive data-port range and network rules. Do not disable TLS or open every firewall port as a workaround.

Verify a small test transfer

The OpenSSH sftp example below assumes that the host key has already been verified. In an empty local working directory, ensure that the filename is unused and create a test file:

printf 'FibaCloud transfer check\n' > 'fc-transfer-test-ç.txt'
sha256sum 'fc-transfer-test-ç.txt'
sftp -o StrictHostKeyChecking=yes -P 22 [email protected]

On macOS without sha256sum, use shasum -a 256. Windows PowerShell provides Get-FileHash -Algorithm SHA256 for local hashes.

At the SFTP prompt, use the following sequence. Replace uploads with your assigned directory. fc-transfer-check must be a new, empty directory dedicated to this test; choose another name if it already exists.

pwd
ls
cd uploads
mkdir fc-transfer-check
cd fc-transfer-check
put "fc-transfer-test-ç.txt"
get "fc-transfer-test-ç.txt" "fc-transfer-returned.txt"
bye

Compare the downloaded copy with the local original:

sha256sum 'fc-transfer-test-ç.txt' 'fc-transfer-returned.txt'

Both digests must match. In FileZilla, upload the same small file and download it under a different local name to perform the same check. An empty transfer queue or matching file sizes alone do not prove identical content.

Upload real files and recover from failures

After verifying the destination and test transfer, upload the real files. For a running application, use its supported versioned deployment and rollback process instead of overwriting active files directly. Transfer permissions must be compatible with the file ownership and access required by the application; do not work around permission problems with 777.

  • Login rejected: Check the account, protocol, chosen key and account permissions.
  • Server identity changed: Verify the change with the administrator before removing a saved key or certificate check.
  • Permission denied: Confirm the destination and account scope; do not request access to another customer’s directory.
  • Different hashes: Do not release the file. Investigate the interruption and client transfer settings, then repeat with a new test.
  • Interrupted transfer: Do not blindly resume a file used by the application. Preserve the last verified version and complete the replacement at a separate destination.

Close the session when finished. Remove only the test file and empty test directory created by this procedure; leave other workspace files intact.

Sources

Technical content and sources reviewed on October 4, 2026. Recheck the relevant official documentation when a version or provider changes.

Leave a Reply

Your email address will not be published. Required fields are marked *