How SFTP Source Authentication Works in Skippr

June 2026

SFTP source authentication in Skippr is standard SSH auth, and the practical decision is whether the pipeline should use a password for simplicity or a private key for long-lived reliability.

Short Answer

SFTP source authentication in Skippr uses standard SSH credentials. The connector supports either password authentication or private_key_path, with the docs recommending private-key auth for long-lived pipelines and environment-variable interpolation when you do use a password such as SFTP_PASSWORD.

That keeps the model plainspoken. If the source connects to sftp.example.com as etl_reader and reads /data/exports/*.json, the real auth boundary is the SSH user that can log in and read that remote path. A successful SSH handshake is not enough if the same user cannot list or read the files the connector is supposed to ingest.

Why Teams Struggle with This

SFTP feels simple because SSH auth is familiar, but source reliability depends on matching the auth method to the operational lifetime of the pipeline. Passwords are easy to start with. Private keys are usually easier to rotate and automate safely over time.

• The connector supports either password auth or a private key, and mixing both casually usually makes rotation harder rather than safer.
• Passwords should be interpolated from environment variables instead of stored directly in config.
• The SSH user needs read access to the exact remote_path or glob the source names.
• Host reachability on the configured port is part of the auth experience because SSH login cannot succeed if the runner never reaches the server.

How Skippr Handles It

Skippr keeps the SFTP auth model explicit and boring, which is a strength. You can see the host, username, port, auth method, and remote path in one short source definition, making it easy to review who the pipeline is acting as and where it is reading.

That clarity is especially helpful when you standardize on key-based auth later. The connector shape does not need to change much. You swap the secret mechanism, keep the same SSH user or replace it with a dedicated pipeline account, and preserve the same remote file scope.

• Standard SSH authentication through either password or private_key_path.
• Environment-backed password handling with ${SFTP_PASSWORD} when password auth is used.
• A documented requirement that the SSH user can read the configured remote path.
• A clean fit for long-lived key-based pipelines without inventing another secret format.

What the First Useful Version Looks Like

The first useful version is one SSH user and one remote directory or glob. That proves the server, credentials, and file permissions together.

If the source will run unattended for a long time, move to private-key auth early. It is the cleaner operating model for recurring SFTP ingestion.