2FA With SSH/SFTP Keys

This page covers 2FA that is enforced at the SSH key itself by the user's hardware token, before the connection reaches Files.com. Files.com's standard 2FA applies at login and is managed by Files.com. These are two separate layers with no interaction between them. If you are looking for standard 2FA, including TOTP apps, SMS, hardware security keys used at login, or sitewide 2FA mandates, see Two-Factor Authentication (2FA).

The ecdsa-sk and ed25519-sk SSH/SFTP key types enforce a second authentication factor at the key itself, using a FIDO/U2F hardware token such as a YubiKey. When a user connects over SFTP with one of these keys, their SSH client prompts them to physically interact with the hardware token before the private key can be used. This is supported by Files.com but controlled entirely by the user's hardware. Because Files.com has no visibility into this second factor, a user with one of these key types will not show as 2FA Enabled in their settings, the 2FA is on the key, not the account.

This approach suits organizations that require 2FA on SFTP connections for human users and need it enforced at the key level rather than at login. It works when the SFTP client does not support appending a one-time code to the password, or when a hardware-enforced second factor is required by policy.

2FA for SSH/SFTP Keys cannot be implemented with other key types.

SSH/SFTP Keys cannot be used with user accounts that require any other form of 2FA. You must configure 2FA to be bypassed for SFTP connections which will allow SSH/SFTP Keys to be used.

Support for ecdsa-sk and ed25519-sk type keys is intended for human users and never for automated processes or scripts. These keys are designed for the 2nd factor of authentication to be provided interactively by a human user.