← All posts

Choosing an SFTP client for Mac: what actually matters

A good SFTP client for Mac gets five things right: it checks host keys properly, keeps your credentials in the Keychain, survives a dropped connection without starting over, shows you what a sync will do before it does it, and behaves like a Mac app rather than a port of something else. Feature lists are long and mostly similar. Those five are where clients actually differ, and where a weak one costs you a production file or a leaked password.

This guide covers what to look for, what macOS already gives you for free, and a short test you can run on any client before you rely on it.

Start with what your Mac already has

macOS ships with OpenSSH, so the command-line sftp tool is already installed. It is capable and worth knowing even if you prefer a graphical app:

sftp deploy@example.com
sftp> cd /var/www/example.com
sftp> put -r dist/*
sftp> reget large-backup.tar.gz

reget and reput resume an interrupted transfer, and sftp -b commands.txt runs a batch of commands non-interactively. The sftp manual page lists the rest.

Finder is less help. Its Connect to Server window can mount FTP servers read-only, but it does not speak SFTP at all. So a graphical client earns its place through the things a terminal makes tedious: browsing two trees side by side, queueing many transfers, comparing folders, editing a remote file in your own editor, and keeping a record of what you did.

Security checks for any SFTP client on a Mac

Host key verification

The first time you connect, SSH has no way to know the server is genuine. A client should show you the server's key fingerprint and its type, let you decide, remember the decision, and then refuse to connect if the key ever changes. A client that silently accepts new keys, or that turns a changed key into a dismissable warning, removes the one protection SSH gives you against interception. We cover how to check a fingerprint properly in how to verify an SSH fingerprint.

Where passwords and keys are stored

Some clients keep saved passwords in a configuration file in your home folder, sometimes only lightly encoded. Anything that can read your files (a backup, a sync service, a script) can then read your server credentials. On a Mac, the right place is the Keychain. Two quick questions tell you a lot: is there any secret in the app's settings folder, and when you delete a saved site, does its password go with it?

Authentication methods

Passwords are the minimum. You will also want public key authentication, keyboard-interactive login (the method most servers use for one-time codes), key-plus-code for servers that demand both, and a way to reach servers on a private network through a bastion. If you use keys, read connecting to SFTP with an SSH key on a Mac first: Mac apps differ in whether they can use ~/.ssh and ssh-agent at all.

Transfers that cope with real networks

Wi-Fi drops and laptops sleep. SFTP can read and write at a byte offset, so there is no reason a client should restart a 4 GB upload from zero after a blip. Look for:

Sync is where a client can really hurt you

Folder sync is the most useful feature and the most dangerous. The questions that matter: does it show the full plan before it runs, does it treat "missing on one side" as "copy it" rather than "delete it", and if it can propagate deletions, is that off by default? A sync that guesses wrong can empty a web root in seconds. Syncing a local folder with a server, with a preview first goes into why this is hard to get right.

Mac-specific things to check

A ten-minute test drive

  1. Connect to a server you have not used with this client before. Does it show the fingerprint and key type before anything else happens?
  2. Start a large upload, then turn Wi-Fi off for ten seconds. Does the transfer pick up where it stopped, or start again?
  3. Save a site with a password, then look through the app's support folder for that password in plain text.
  4. Make a test folder pair, delete a file on one side, and run a sync. Does the client copy it back, delete it from the other side, or ask?
  5. Open a remote config file in your usual editor, save a change, and check the server copy.
  6. Delete the saved site and check whether its credentials are gone from the Keychain.

How Wharf approaches it

We built Wharf around that checklist, so here is how it answers each point. It connects over SFTP, FTP, FTPS (explicit or implicit) and Amazon S3, including S3-compatible services through a custom endpoint. Authentication can be a password, an SSH key, an SSH key plus a two-factor code, or keyboard-interactive on its own, and any SFTP site can be reached through another saved site acting as a jump host.

On first connection Wharf shows the server's key type and SHA256 fingerprint, with the ssh-keyscan command to check it, and remembers your decision. If the key later changes it refuses to connect and shows both the expected and the received fingerprint. Passwords, keys and passphrases go in the Keychain, and removing a site removes them too.

SFTP and FTP transfers resume after a dropped connection, and the Settings window sets simultaneous transfers, connections per site, retry attempts and a bandwidth limit. SFTP uploads keep the local modification time. Sync shows a review sheet before anything moves, with conflicts showing both sides' sizes and dates, and deletion propagation stays off unless you tick it for that run. There is also Follow Log… for live log tails, Edit in Default App, remote Quick Look, an activity log with CSV export, and Shortcuts actions. The features overview is on the Wharf homepage.

There are two editions. The one from the website can be given Full Disk Access. The Mac App Store edition is sandboxed and reaches only folders you grant. Neither uses ssh-agent: you import a key once and it lives in the Keychain. The support page explains both, and there are no accounts and no analytics in either (see privacy).

Whichever client you choose, run the test drive above first. Ten minutes on a test server tells you more than any feature list.