Authentication & Negotiation
When an SFTP job fails to connect to Files.com with no matching host key type, check for a compatible server-identity algorithm. A job that logs in but cannot upload into the agreed folder instead needs its account's path and permissions checked. Knowing where the connection failed lets you address the cause instead of changing a password that was never the problem.
Files.com handles the service connection when both businesses use Connected Sites. The negotiation and credential choices below matter when a partner uses an external protocol or client, as described in our connection recommendations.
Connection Stages
A connection begins with the client resolving the hostname and reaching the service. SSH or TLS negotiates the protocol and algorithms and establishes a protected connection, with the applicable server-identity checks. Only then does the client authenticate using a method the service permits, after which the account's permissions govern its file operations.
The precise exchange differs between protocols, but the diagnostic distinction remains useful:
| Observation | Question to resolve |
|---|---|
| Name resolution fails, connection times out, or connection is refused | Is the client reaching the correct endpoint and port through a permitted network path? |
| No matching protocol version, cipher, key-exchange method, or host-key algorithm | Do the client and server support a common choice for the reported algorithm? |
| Certificate validation or host-key comparison fails | Does the presented server identity match the trusted identity for this endpoint? |
| Authentication is rejected | Does the client supply the credentials and method required for this account? |
| Login succeeds but an operation is denied or files are missing | Does the account have the required permission and the correct view of the path? |
For FTP, successful login also leaves the separate data-connection path to check. A listing or upload that times out can be a network problem even though authentication succeeded.
Compatible Algorithms
The two sides need an acceptable choice for each required cryptographic role. In SSH, key exchange, host-key signatures, traffic encryption, and message integrity are distinct choices. The phrase “cipher error” is sometimes used loosely for failures in any of them.
Messages such as no matching cipher found, no matching key exchange method found, or no matching host key type found tell you which choice the systems could not agree on. The last of these concerns supported server signature algorithms. It differs from a changed-host-key warning, which means the presented key does not match the identity the client trusts.
An RSA key is not inherently limited to the older SSH ssh-rsa signature method. RSA with SHA-2 signatures uses the same key format with newer signature algorithms. Check the client's version and supported signatures before replacing a working RSA key or enabling older algorithms.
TLS also requires agreement on a protocol version and cipher before application login. If the server requires a newer version than the client supports, correct account credentials cannot make the connection work. Include any network gateway in the investigation because it can affect the TLS connection the client sees.
Resolve compatibility with the operators of both endpoints. Prefer updating the client or server to a mutually supported modern configuration. Where a business requirement necessitates a compatibility exception, understand its scope and plan the dependent system change. Files.com's Transfer Encryption and SFTP legacy compatibility document the actual site choices; generic SSH settings are not substitutes for them.
Authentication Methods
Authentication proves control of an accepted credential. Authorization then determines the account's permitted work. A partner can log in successfully and still lack permission to upload into your intake folder or overwrite yesterday's file.
| Method | What the client presents or proves | Operational implication |
|---|---|---|
| Password | Knowledge of a shared account secret | Protect the connection and stored secret; changing a shared password affects every job using it |
| SSH key | Possession of the private key corresponding to an authorized public key | The private key stays at the client; the server registers the public portion |
| SSH key plus password | Both the accepted key and an account password | Both must be configured and supplied when the server requires them; one does not replace the other |
| API key or token | Possession of a service-issued secret | Treat it as a credential, even though its name contains “key”; its scope and lifetime follow the service's rules |
| Client certificate | Possession of a private key corresponding to a certificate accepted for client authentication | Requires an explicitly supported certificate-authentication arrangement on both sides |
Although its name contains “key,” an API key is usually a secret value rather than a public/private pair. Other services, including S3, use access credentials to sign requests. The service's authentication documentation determines which method the client needs to use.
TLS server certificates, TLS client certificates, and AS2 message certificates have separate jobs. HTTPS does not automatically require a client certificate. Ask a partner requesting certificate authentication which protocol layer and identity it means. Files.com's authentication methods describe its supported account choices. Its FTP service and outbound FTP connections do not support client-certificate authentication.
Proof Without Sending the Private Key
In SSH public-key authentication, the client signs data tied to the connection and authentication request. The server checks that signature against the public key registered for the account, confirming that the client can use the matching private key without receiving the private key itself.
This is why the public portion is sufficient for account setup but cannot perform a login on its own. It also needs to be registered on the intended account: a key associated with another account does not grant access to this one.
A private-key passphrase protects the stored key file and is separate from the remote account's password. Even with key-only authentication at the server, a client may prompt for a passphrase to unlock its local key. For an unattended job, the client needs a supported way to access that credential without waiting for someone to answer.
People and Unattended Systems
When a person signs in, the system can ask them to complete SSO or provide a changing second factor. A nightly transfer needs a machine account with credentials its software can use unattended. Someone still needs to own and maintain those credentials, even though no one is present for each login.
Requiring a static password and an SSH key is distinct from requiring a changing one-time code. Confirm the actual policy and client behavior. Files.com's protocol-compatible authentication guidance covers its interaction with 2FA and unattended transfers.