SFTP (Outbound to a Remote)

Connect a partner's or your organization's SFTP server when Files.com needs to collect or deliver files using the account that server provides. Files.com acts as the SSH client. The remote account determines which paths and operations are available; Files.com folder permissions separately control users accessing a mounted location.

A Mount gives access to the remote working files through Files.com. A Sync transfers a separate copy between locations. For a partner that connects into Files.com instead, use the inbound SFTP guidance.

Connection Details

Select SFTP when adding a Remote Server. Obtain the host, port, account, and authentication requirements from the remote operator. SFTP uses SSH; FTP and FTPS require a different connection type.

Connection Routing

A public connection needs a publicly reachable endpoint and remote firewall rules permitting the source addresses for the chosen route. With dedicated addresses, Connection Routing can use the site's default addresses or an eligible Custom Domain. Give the operator every outbound address displayed for that selection.

Agent routing reaches an SFTP server from the Agent's network, including private servers. The SFTP service need not be exposed to the public internet. The Agent must still be able to reach both Files.com and the remote service, and its network determines the source address seen by that service.

Where Data Regional Routing is available, select the region required for the connection. A routing choice affects the connection path; it does not move the remote files to a different storage region.

Authentication

Enter credentials directly or select a saved entry from the Remote Server Credential Manager. Files.com supports private keys in OpenSSH, PuTTY (.ppk), and SSH2 formats. When generating a key in the connection form, Files.com creates a 4096-bit RSA key pair and provides its public key for installation on the remote account.

Give the remote administrator the public key, while keeping the private key in the connection or its saved credential. The server must associate the public key with the configured username. A password-and-key account requires both credentials; supplying one does not satisfy the other requirement. Stored Remote Server credentials are encrypted within Files.com.

Server Host Key

The Server Host Key pins the remote SFTP server's public host key. If you do not provide one during setup, Files.com automatically detects and stores a host key, preferring plain host keys over OpenSSH host certificates. If the server only offers a supported host certificate, Files.com stores the complete certificate as the pin.

By default, Files.com connects only when the remote server presents the pinned host key and proves it holds the matching private key. This verifies the same host key on each connection, including connections to a pool of servers that share that key.

An existing pin takes precedence over the default host key preference. Files.com prefers modern signature algorithms for the pinned key and retains compatibility with servers that require legacy signatures.

When a certificate is pinned, Files.com requires that exact certificate and proof of possession of its matching private key. It does not evaluate the certificate authority (CA) signature, the hostnames listed in the certificate (its principals), or its validity period.

A Server Host Key is not the same as a Public or Private Key pair for user authentication. Those are a separate key related to the user. Server Host Keys apply to the entire remote server and not a specific remote user.

Changes to a Server Host Key

The pin remains in force until an administrator changes Server Host Key. Certificate expiration alone does not end the pin. Renewing a pinned certificate changes the certificate and causes a mismatch even if its underlying public key stays the same. Renewing a certificate does not affect a plain-key pin when the server continues to offer that same plain key.

To replace a pin, obtain and verify the replacement host key or certificate with the remote server's administrator, then update Server Host Key. To use a plain-key pin, confirm that the server offers the plain host key during SSH negotiation.

By default, Files.com rejects connections when the server presents a different host key. Connections succeed again when the server presents the saved key or an administrator updates Server Host Key after verifying the change. This check helps prevent files and credentials from being sent to a different server presenting an unexpected key.

You may also configure Files.com to allow non-matching server host keys. This behavior is insecure and not recommended.

Concurrent Connections

Max connections controls parallel connections to the remote SFTP server. The recommended default is 25. Reduce it when the operator requires a lower limit or the server cannot sustain the combined workload. A low setting can make operations queue for a connection; a setting above the server's capacity can cause failures rather than faster transfers.

Consider all Mounts, Syncs, and Automations using the destination, along with connections from other applications. Files.com makes a best effort to honor the setting, but brief bursts can exceed it during connection transitions. The remote service's own limits still apply. Connections from shared addresses can also encounter popular-counterparty limits.

Staging Folder for Move-Based Operations

Use Moves To Emulate Atomic Uploads to SFTP uploads into a staging folder on the remote system, then moves the completed file to its destination. This helps a receiving application avoid picking up contents while they are still uploading.

The connection needs permission to upload into the staging location and move the completed file to its destination. Keep the staging folder outside the receiving application's pickup path. The remote system's behavior still determines the atomicity of the final operation.