SFTP Migration Setup — Password or PEM Key Authentication

SFTP (SSH File Transfer Protocol) is the encrypted, modern replacement for FTP. It rides on top of an SSH connection — same protocol that powers remote shell access — so credentials, file metadata, and file bytes are all encrypted end-to-end.

Univaultport supports both authentication modes:

Password — easy to set up, lower security. Many production hosts disable it entirely.
PEM private key — production standard. The corresponding public key lives in the server's ~/.ssh/authorized_keys.

Step 1 — Collect server details

You'll need:

Setting	Example	Notes
Host	`sftp.example.com` or `203.0.113.10`	No protocol prefix.
Port	`22`	Default SSH port. Some hosts use a non-standard port for security.
Username	`migrator`	The SSH/SFTP user on the server.
Auth	Password OR private key	At least one required. Don't supply both — only one will be used.
Root path	`/var/uploads`	Optional. Scopes the connector to a sub-folder.

Step 2 (Path A) — Password authentication

The simplest path. Just paste the password.

Host:        sftp.example.com
Port:        22
Username:    migrator
Password:    your-account-password
Private Key: (leave blank)
Root Path:   /var/uploads

Pros: quick setup. Cons: many production hosts disable password auth in /etc/ssh/sshd_config (PasswordAuthentication no). If the server is locked down, you'll see All configured authentication methods failed — switch to key auth (Path B).

Step 2 (Path B) — Private key authentication

The production-grade option. Two pieces:

Private key lives in Univaultport (encrypted at rest).
Public key lives on the SFTP server, in the target user's ~/.ssh/authorized_keys.

Generate a key pair

On any machine with OpenSSH installed:

ssh-keygen -m PEM -t rsa -b 4096 -f ~/.ssh/asset-migrator -N "" -C "asset-migrator"

This produces two files:

~/.ssh/asset-migrator — private key (paste into Univaultport)
~/.ssh/asset-migrator.pub — public key (copy onto the server)

Install the public key on the server

SSH into the server as the target user (one time, however you currently access it), then:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
cat >> ~/.ssh/authorized_keys <<'EOF'
ssh-rsa AAAAB3Nz... asset-migrator
EOF
chmod 600 ~/.ssh/authorized_keys

Paste the contents of ~/.ssh/asset-migrator.pub (the public key file, with the ssh-rsa ... prefix) into the <<'EOF' block.

Paste the private key into Univaultport

Copy the entire contents of ~/.ssh/asset-migrator (the private key file) including the header and footer:

-----BEGIN RSA PRIVATE KEY-----
MIIEpAIBAAKCAQEAyo...
...many lines...
-----END RSA PRIVATE KEY-----

Paste into the Private Key (PEM) field in the connector wizard. Leave the Password field blank.

Step 3 — Paste credentials into Univaultport

In the connector wizard:

Host + Port
From Step 1. Default port is 22.
Username
The SSH user name on the server.
Password OR Private Key
Fill exactly one. Private key is recommended for production.
Root Path (optional)
Scopes the connector to a subdirectory. Defaults to the user's home directory.

Click Save & test. Univaultport will:

Open an SSH connection to host:port
Authenticate with the credential you provided
stat the rootPath to confirm it exists and is readable
list rootPath to confirm we have directory read permission

If all four pass, the connector turns green.

Common errors

Error	Cause	Fix
`All configured authentication methods failed`	Server rejected password / key	Verify with `ssh user@host` first. If `ssh` works but Univaultport doesn't, check key format (must be PEM)
`Permission denied` mid-migration	User can read but not write the destination	Check `ls -ld <destPath>` on the server; grant `w` to the user
Connection refused	SSH daemon not running on this port	`nc -zv host 22` to confirm, or ask the admin for the right port
`No such file`	rootPath doesn't exist for this user	`ssh user@host pwd` to see their home, then `ls` to find the right path
Timeout	Firewall blocking, or server's slow ssh_keyscan	Check security groups / firewall; raise tolerance on the server

Performance characteristics

SFTP supports multiplexed requests over a single connection — much faster than FTP at small-file workloads. However Univaultport currently serializes ops on the SFTP connection to avoid races with the underlying library's working state. We may add per-connection parallelism in a future release.

Typical throughput:

Small files (< 1 MB): 100-300 ms per file (latency-bound)
Large files (> 100 MB): network-bandwidth-bound, identical to scp

For very large migrations (10 GB+), SFTP is significantly faster than FTP because the SSH transport supports better congestion control.

Security best practices

Use key auth, not passwords — PasswordAuthentication no in /etc/ssh/sshd_config on the server.
One key per integration — generate a dedicated key for Univaultport rather than reusing personal SSH keys. Makes rotation and revocation trivial.
Restrict the user — create a dedicated SFTP-only user with a chroot jail to the asset directory. Search "openssh sftp chroot" for the standard recipe.
Audit authorized_keys — periodically. Univaultport's audit log records which user triggered which migration, but doesn't track server-side key presence.

Univaultport encrypts the PEM key AES-256 at rest and never returns it in API responses.

Next steps

With SFTP connected, common patterns are:

SFTP → S3 / GCS for migrating from a legacy server-hosted setup to a cloud bucket
Cloudinary → SFTP for delivering processed assets to a partner's secure server
SFTP → SFTP for moving between two SSH hosts during a server migration

Folder hierarchy is preserved on writes — SFTP supports real directories on both sides.

How to Connect SFTP to Univaultport (Password or PEM Key)