Secure File Transfer Protocol (SFTP) is a protocol for remotely transferring files between two different computers or file systems via the Internet. Configuring an SFTP connection can be tricky. This article describes some techniques for troubleshooting failed connections and describes common issues that Slate users may encounter.

Validate your connection settings

If you encounter issues connecting to the Slate SFTP server, try using SFTP Connection Validation to diagnose any configuration issues such as an incorrect password or disallowed IP address.

Parallel test your connection

If you are having trouble connecting to a Slate SFTP server using one SFTP client, try another, such as Filezilla or WinSCP.  If you can access the server and path from the third party service, your credentials are probably correct—meaning something is misconfigured in your original tool.

User ID changes may take up to 1 hour to propagate through all parts of Slate

If the User ID was changed and the query immediately exported on demand, the query may not have incorporated the username changes.

SFTP connections to/from Slate were disallowed by your network’s firewall

Check your firewall: Are Slate connections allowed? Outbound connections from Slate are initiated from the IP addresses listed in the Outbound Networks article should be included in your firewall whitelist.

SFTP connections to/from Slate were initiated from IP addresses that are not in your User’s “Allowed Networks”

Check the user account you are attempting to connect with. Is your external IP address listed in the Allowed Networks field for the service account? Does your CIDR range include all of the addresses it should?

SFTP connection originates from a high risk IP address

Check the IP Threat List:  Slate uses BrightCloud Threat Intelligence to identify and block IP addresses at our firewall that have a low reputation/high risk and that may be a threat.  Use the BrightCloud IP address search to check the reputation of the IP address.  If the address is found to have a high risk, then it is being blocked.

If the IP address is being blocked, you will need to work with your ISP to remove the High Risk status for the IP address. You can also submit a request to change the IP threat status through BrightCloud.

You are requesting a path to which your user account does not have access

Check your user account for path restrictions. When a restriction has been added, users will only be able to access paths to which they have been explicitly granted access. In the example below, the User has been granted access to the /incoming/SIS/ path. If the user attempts to access other paths, such as /incoming/test_scores/, access will be denied. Some SFTP clients may interpret this as the end of the transaction and terminate the connection.

Your path restriction is missing a trailing /

Path restrictions must include a trailing forward slash / or Slate will assume that you should have access to a file rather than the path. If the user attempts to access the truncated path, access will be denied. Some SFTP clients may interpret this as the end of the transaction and terminate the connection.

Common issues when using a public / private key pair

One method of authentication that can be used when connecting to / from a Slate SFTP server is an SSH / SFTP key pair. This authentication method is considered generally more secure than password authentication but has a few common pitfalls, described here.

The private key exists on your Service Account (Remote) but is not installed for that username on the remote server

Be sure the corresponding public key is installed on the remote server for this User ID Some users find it helpful to test the connection using a username and password to rule out an issue with the public key pair.

The private key on your Service Account (Remote) does not match the public key installed on the remote server

Double check key itself: does it match the key on the remote server for this User ID?

The key pair are of the wrong type or incorrectly formatted

If you are using a keypair, it must be an RSA key:

It must also include the following comments around the key itself:

-----BEGIN RSA PRIVATE KEY-----

Followed by the key, then:

-----END RSA PRIVATE KEY-----

If you are using PuTTYgen to generate your RSA Key: Use Conversions > Export OpenSSH Key to format the newly generated Private Key correctly. You will want to save the OpenSSH Key without a passphrase by ignoring PuTTYgen's warnings.