Skip to content

SFTP / FTPS Troubleshooting

QIE's FTP-family receivers and senders (plain FTP, FTPS, and SFTP) share a single staged connection diagnostic for the cases where a server is reachable from a desktop client but not from QIE, or simply for testing when configuring these nodes. This page explains the diagnostic and the legacy SHA-1 algorithm option.

The connection diagnostic

Every FTP-family node has a Test button (source nodes, destination nodes, and the FTP external variable source). Running it opens a staged diagnostic dialog that walks the connection one step at a time instead of returning a single pass/fail message:

  • TCP connect: opening a socket to the host and port.
  • Server banner: the server's greeting (FTP 220 line, or the SSH identification string).
  • TLS handshake (FTPS) / key exchange (SFTP), the encrypted channel is negotiated.
  • Server identity: displays the SFTP host key or the FTPS server certificate fingerprint.
  • Authentication: logging in with the configured credentials or SSH key.
  • Directory listing: listing the configured folder over the data channel. For a source or external variable test the stage also reports how many listed files match the configured file name or wildcard, and warns when none match (the folder lists fine, but the channel would currently collect nothing: often a typo in the file name or pattern).
  • Write test: for destination tests, an opt-in upload-and-delete of a temporary file.

Each stage shows ✓ / ⚠ / ✗ with a timing, so a slow or failing step is obvious at a glance. When a step fails, the dialog shows the classified cause and a remediation hint, the resolved (password-masked) connection URI, and the full technical log for support.

\"FileZilla works but QIE does not\"

This is almost always an algorithm or certificate mismatch. It usually surfaces at the TLS handshake / key exchange or Server identity stage, but when a modern SSH client and an older server share no public-key algorithm it surfaces at the Authentication stage as an "Auth fail" even though the key is correct. Run the diagnostic and read the failing stage's remediation hint: for that authentication case it points at adding publicKeyAcceptedAlgorithms=ssh-rsa (and, if the host key is also legacy, serverHostKeys=ssh-rsa) to the node's Custom Apache Camel Parameters.

Server identity

This stage is informational and never blocks the connection, matching the live channel. For SFTP the host key is captured but not verified (QIE auto-trusts SSH hosts). For FTPS the stage reports whether the server certificate validates against the JVM trust store; a self-signed or private-CA certificate not present in that trust store is flagged as an informational warning: the connection still succeeds, since the live channel accepts any server certificate.

Legacy SHA-1 algorithm option

The qie.enableCamelSFTPSha1CipherSuites Java option globally re-enables legacy SHA-1-era SSH algorithms (ciphers, key exchange, host-key, and MAC) for SFTP. Prefer setting only the algorithms a specific server needs per-channel over enabling all of them globally.

To set a specific (non-default) SSH algorithm list on a single channel rather than globally, add the corresponding Apache Camel SFTP parameters to the node's Custom Apache Camel Parameters field, for example ciphers=…, serverHostKeys=…, publicKeyAcceptedAlgorithms=…, or preferredAuthentications=….

The node's Test button applies these SSH parameters too, so the connection diagnostic negotiates and authenticates exactly as the live channel does, rather than falling back to library defaults.