Skippr Docs

Appearance

How to Manage SFTP Source Credentials in Skippr ​

July 2026

Keep SFTP source credentials safe by using a dedicated SSH key when possible, leaving host and remote path visible in config, and falling back to SFTP_PASSWORD only when the server truly requires password auth.

Short Answer ​

Manage SFTP source credentials in Skippr by preferring the documented private_key_path flow for long-lived pipelines and using password: ${SFTP_PASSWORD} only when the server requires password auth. The safe split is to keep host, port, username, and remote_path visible in config while protecting only the key material or password.

That matches how the connector is documented. SFTP auth is either password based or SSH-key based. The pipeline should say which server and path it reads, but it should not expose the password or bury a shared private key in application config.

Why Teams Struggle with This ​

SFTP secrets often spread because teams treat file pickup as simple plumbing and reuse personal credentials or pasted passwords. The result is a pipeline that works once but is difficult to rotate and harder to trust.

  • Putting a literal SFTP password in config creates an avoidable secret leak.
  • Reusing a personal SSH key for an automated pipeline makes ownership and rotation unclear.
  • The remote path should stay visible because it defines what files Skippr can pull.
  • If the SSH user cannot list or read the target path, changing the credential storage format will not fix the permission boundary.

How Skippr Handles It ​

Skippr keeps SFTP readable because only the auth material needs protection. The server name, username, port, and remote path can remain in plain config, which makes the integration easier to review and easier to support.

When password auth is unavoidable, ${SFTP_PASSWORD} is still better than a literal secret. When key auth is available, a dedicated automation key usually gives a cleaner long-term operating model.

  • Supports password auth with password: ${SFTP_PASSWORD}.
  • Also supports SSH key auth through private_key_path, which is preferable for long-lived jobs.
  • Keeps host, port, username, and remote_path visible and reviewable.
  • Fits a dedicated SSH account with read access only to the export directory Skippr needs.

What the First Useful Version Looks Like ​

The first useful version is one SFTP host, one automation user, and one remote file pattern such as /data/*.json. That is enough to prove the auth boundary and the file contract together.

If the server supports SSH keys, start there. If it does not, keep password auth behind SFTP_PASSWORD and plan a clear rotation procedure before the integration becomes production traffic.