Authenticating With 2FA via FTP, SFTP, or WebDAV

Files.com accepts a 2FA code appended to your password when you connect over FTP, SFTP, or WebDAV. It works, but it is rarely the right choice. These protocols have no way to prompt for a second factor, so the code has to travel inside the password field.

Whether to use 2FA with these protocol-based transfers depends on whether a person or a machine is connecting. For a machine, the answer is to use key-based authentication instead because a machine can't easily supply a second factor during authentication. When a person is connecting, 2FA is more appropriate, but using the Files.com Desktop App or CLI App rather than FTP, SFTP, or WebDAV will offer the best experience.

Enabling 2FA for Existing FTP/SFTP/DAV Users

Once 2FA is required, either site-wide or for their account, a user who authenticates with a password or an SFTP/SSH key cannot connect over FTP, SFTP, or WebDAV until they log into the Files.com web app and set up a 2FA method. Enabling the bypass for these protocols does not avoid that, because the per-user bypass option is only selectable during that same setup.

Users who authenticate with an API key are unaffected, because those logins never involve 2FA.

Plan for this before turning on a mandate. Move the affected accounts to API keys, exempt them from the mandate, or expect every password and key user to need a web login before their transfers resume.

Authenticate Automation With a Key

Scripts, integrations, and scheduled transfers cannot answer a verification prompt, so 2FA does not belong on these accounts at all. Authenticate them with an SFTP/SSH key for SFTP, or with an API key for FTP, SFTP, or WebDAV.

To use an API key, set the login name to @api- followed by either the key's ID or the key's name, for example @api-5373469 or @api-botsync, and use the API key itself as the password. The value after @api- identifies the key, not the user who owns it.

Keep machine accounts separate from the people who sign in interactively, and apply the Shared/Bot user setting so the account authenticates without an interactive challenge.

Move Human Users to the Desktop App or the CLI

A person who needs 2FA and needs file transfer is better served by a client built to handle both.

The Files.com Desktop App signs in the same way as the web interface, including your 2FA method, then stores a dedicated API key for the session. The CLI App prompts for the second factor once after your password and keeps you logged in until you log out or the session expires.

Both answer the second factor once, at login, instead of on every connection. Both offer improved transfer speeds because they transfer even a single file over parallel connections.

When a Third-Party SFTP Client Is Required

Some connections cannot move to a Files.com client. A trading partner's IT policy may mandate a particular SFTP application, or an established workflow may be built around one. Two options give you a second factor without appending codes.

An ed25519-sk or ecdsa-sk SSH key enforces the second factor at the key itself, using a hardware token the user touches before the private key will work. Files.com never sees that exchange, so the account does not show as 2FA Enabled, and the protection is real.

The Combination of Password and SFTP/SSH Key (SFTP only) authentication method requires both a password and an SSH key on every SFTP connection. Two independent credentials are not the same as a changing second factor, so this is a two-factor model rather than true 2FA, but it satisfies policies that call for a key and a password together.

If neither fits, bypass 2FA for FTP, SFTP, and WebDAV on those accounts and keep the 2FA mandate for web and API access, where it works properly.

Appending a Code to Your Password

When none of the above applies, a user with a supported 2FA method authenticates by typing their password and then the current 2FA code, with no separator, into the password field. With a Yubikey in native mode, insert the key and press its button immediately after typing the password, and it enters the code itself.

Only three methods work this way: Yubikey native, authenticator apps, and SMS. Yubikey WebAuthn, other FIDO hardware keys, and email verification cannot be used over these protocols at all.

Do not choose SMS for an account that connects this way. Files.com sends an SMS code in response to a web sign-in, not an SFTP connection, so the user has to start a login in the web interface every time they want to connect with a file transfer client. Use an authenticator app instead.

File transfer clients routinely open several connections at once, and these protocols cannot ask for a new code on each one. Once your password and code authenticate a connection, Files.com accepts the same password and code for more connections over the same protocol, from the same source IP address, to the same Files.com server address. That holds until the session from the first sign-in ends under your site's Session Expiration setting.

A connection from any other IP address cannot use a code that has already been used. Someone who sees your code after you connect cannot use it to sign in from their own address.

Files.com hostnames resolve to several server addresses. A connection that reaches a different server needs a new code.