When encountering the error “Authentication exception, private key is invalid" the issue typically relates to the private key being used by the InfoSum platform to authenticate with the clients sFTP server. Here is a troubleshooting guide:

Common Causes of "Private Key is Invalid":

• Mismatched public/private keys: The key provided by the customer in the import configuration does not match the key for the supplied user name that is configured on the sFTP server. Please ensure that the correct public key is in the `authorized_keys` file for the supplied username
• Incorrect key format: The private key is in an unsupported format (e.g., OpenSSH vs. PEM).
• File permission issues: The private key file or the server's `authorized_keys` file has incorrect permissions. This is something that you can check on your server (see step 1 below)
• Corrupted key: The private key file is corrupted or incomplete.
• Expired or revoked key: The key may have expired or been revoked, especially if using a managed key system.

Troubleshooting Steps:

1. Check Server-Side Configuration & Private Key Used

Server settings

Ensure the server is configured to accept key-based authentication and that it is properly referencing the `authorized_keys` file.

• Confirm the user ID supplied matches the one expected on the server
• Confirm that SSH key authentication is allowed in the server's `sshd_config` file:

     ```bash

     PubkeyAuthentication yes

     ```

• Check the permissions on the server where the public key is stored. If the `authorized_keys` file or the `.ssh` directory for the user has the wrong permissions, SSH might ignore the key:

     ```bash

     chmod 700 ~/.ssh

     chmod 600 ~/.ssh/authorized_keys

     ```

Private key check

Verifying the correct Private Key used is in the context of the user that was configured in the importer/ICC. e.g. if it's connecting as my user, then that user has to have the correct matching key

• If you're unsure which key pair is associated with the connection, verify this with the server administrator or check which public key is listed in the server's `authorized_keys` file (typically located in `~/.ssh/authorized_keys` on the server).
• Ensure the private key is correct and matches the corresponding public key stored in the server's `authorized_keys` file: you can generate the public key from the private key and compare it to the one in the `authorized_keys` file. This will output the public key from the private key.:

   ```bash

     ssh-keygen -y -f /path/to/private-key.pem

     ```

2. Check the Private Key Format

The private key must be in PEM format. Common SSH key formats include:

•   PEM format: Base64-encoded, starts with `-----BEGIN PRIVATE KEY-----` or `-----BEGIN RSA PRIVATE KEY-----`.
•   OpenSSH format: May start with `-----BEGIN OPENSSH PRIVATE KEY-----`.

Ensure the correct format is being used, as we only accept PEM format. If needed, convert the key format using OpenSSH tools:

• Convert to PEM format (if in another format):

     ```bash

     ssh-keygen -p -m PEM -f /path/to/private-key

     ```

3. Test the Private Key Manually

Try using the private key to manually authenticate via SSH or SFTP to ensure it’s functioning correctly. NB: If the SFTP server has IP white-listing, the IP address of the machine being used for the test must be white-listed prior to testing.

Example using SFTP:

   ```bash

   sftp -i /path/to/private-key.pem username@hostname

   ```

• If this fails with the same error, you’ve confirmed the problem lies with the private key or its configuration.

4. Check for Key Expiration or Revocation

• If the key was created using a system that supports key expiration or revocation, verify that the private key hasn’t expired or been revoked.
• Some systems (like some key management solutions) may impose expiration dates on keys or revoke them for security reasons. In such cases, a new key would need to be generated.

5. Look for Error Messages in Server Logs

• If possible, check the server’s SSH logs for more details. These are often located in `/var/log/auth.log` or `/var/log/secure`, depending on the system.

For example:

     ```bash

     tail -f /var/log/auth.log

     ```

• Look for clues related to the rejected key.