What Access Skippr Needs to Read from SFTP

June 2026

SFTP access is a classic SSH file-read problem: the login has to reach the server and list and read the exact remote path you configured.

Short Answer

Skippr needs an SSH user that can read the selected remote_path, plus network access to the SFTP host on the configured port, usually 22. Authentication can be password-based or private-key-based, but either way the meaningful requirement is that the SSH identity can list and read the files behind the remote path you gave Skippr.

A typical setup is host: sftp.example.com, username: ingest, and remote_path: /exports/*.json with a private key in ~/.ssh/id_rsa. If that user can log in but cannot list /exports or read the matching files, the connector is not actually ready even though the SSH handshake itself succeeds.

Why Teams Struggle with This

SFTP access gets muddled when teams stop at authentication. A valid username and key prove very little if host-based controls, chroot rules, or remote path permissions still keep the user away from the files the pipeline is supposed to ingest.

• The SSH user needs read access to the exact remote file path or glob pattern you configure.
• The runner must reach the SFTP host and port from the environment where Skippr executes.
• Password auth works, but long-lived pipelines are usually cleaner with a private key and a stable service user.
• A remote path that is syntactically valid can still be wrong if the user lands in a restricted directory tree and cannot see the intended files.

How Skippr Handles It

Skippr keeps SFTP access understandable because the connector maps directly to SSH concepts: host, port, username, password or private key, and remote path. That is better than a generic file-source abstraction because it lets infrastructure teams review the exact network and user boundary being granted.

The docs also push password secrets into environment variables and treat key-based auth as the better long-lived option. Once the first run works, you know the SSH identity, path permissions, and network path are all aligned well enough for repeated extraction.

• Supports password or private-key authentication for the SSH user.
• Reads one explicit remote path or glob rather than scanning an unknown file tree.
• Depends on the standard SFTP host and port being reachable from the runner.
• Keeps credentials out of skippr.yaml through environment-variable interpolation.

What the First Useful Version Looks Like

The first useful version is one service account, one remote directory, and one small file pattern you can validate over the same SSH path the production runner will use.

After that, widen the glob carefully, because path visibility and file naming conventions are usually the first operational boundary you want to keep under control.