SFTP (SSH) Keys

SFTP supports authentication using cryptographic keys, as opposed to a username and password. SFTP keys, when added in Files.com, provide access via SFTP only, and do not confer any access via APIs, SDKs, or the web.

The use of an SSH Key to authenticate is not mandatory. SSH Keys can either be used as an optional alternative to a password, or as a mandatory replacement for a password, depending on how the system is configured.

SSH Keys will never grant access to a shell or system prompt at Files.com and are only for SFTP protocol usage.

An SSH Key is really a matched pair: a public key and a corresponding private key.

When generating an SSH key, the two halves (public and private) will always be created.

The private key must never be shared, and should remain under the control of the user, script, or system, that will be using SFTP to connect to an SFTP account. The private key is the equivalent of your password and should be protected similarly.

The public key can be shared with any system that needs to provide secure access to the user, script, or system, that owns the corresponding private key. The public key does not need to be kept secret and can be distributed freely. The public key has no power, authorization, or authority without the corresponding private key.

Never share a private key. Whenever exchanging SSH keys for use with SFTP or SSH access, only send or share the public key portion.

SSH Keys can be imported into Files.com and used to authenticate users.

Users can add their own SSH public keys themselves within the Files.com web interface. After logging in with their username and password, they can select their username at the top right of the page then select My account > SFTP keys > Add SFTP key, and paste in the public key portion of their SSH key.

Administrators can add an SSH key to any Files.com user account. Type "SFTP/SSH Keys" in the search box at the top of every page and then click the matching result. Click Add SFTP key, and paste in the public key that was provided by that user. Once imported, the user account can use their SSH private key to authenticate and gain access to Files.com using the SFTP protocol.

SFTP public keys can also be added programmatically via our Public Key REST API.

Public keys are not viewable once saved, but can be identified by their unique key fingerprint. If you need to verify that you have the correct key, you can view the public key's fingerprint. Type "SFTP/SSH Keys" in the search box at the top of every page and then click the matching result. All of the keys for the selected user are listed, with the title given to the key, the fingerprint, and the option to delete the key from Files.com. If you believe that the key pair has been compromised or is no longer in use, remove the key by clicking the Delete button.

We support the ED25519 (including ED25519-sk), ECDSA (including ECDSA-sk), RSA, and DSA encryption types for keys.

We recommend using ED25519 keys because they are the most secure. RSA and DSA keys are considered less secure and slower than ED25519.

If using an RSA key, we recommend using a key length of at least 2048 bits.

When a user account is configured with a password, the SSH Key will act as an additional method of authentication. That is, both the SSH Key or the password can be used to authenticate an SFTP connection by that user account. A user account is considered to have a password when the Authentication Method for that account was configured to use any of the following options:

• Password
• Imported hash
• Email sign-up
• Any of the available Single-Sign-On (SSO) methods

When a user account is configured with no password, the SSH Key will act as the only method of authentication. That is, only the SSH Key can be used to authenticate an SFTP connection by that user account. A user account is considered to have no password when the Authentication Method for that account was configured to use the None option.