Fix SFTP Authentication Failures in NetDrive — Keys, Passwords, and Ports

You added an SFTP connection in NetDrive, clicked Connect, and got an authentication error — or the drive timed out silently after thirty seconds. SFTP authentication failures are the most common stumbling block when mounting Linux servers, NAS devices, and shared-hosting accounts. Almost every case traces back to one of three root causes: wrong credentials or host settings, SSH key format mismatch, or a stale host-key cache entry.

NetDrive drive manager showing Google Drive, S3 and pCloud mounted as drive letters

Mounted clouds appearing as native drives in Windows File Explorer

Mount Any SFTP Server as a Native Drive

NetDrive lets Google Drive, OneDrive, S3, SFTP, WebDAV and more appear as native drives on Windows and macOS — no syncing, no full downloads.

Password and SSH key authentication both supported
Works with Linux servers, Synology/QNAP NAS, and hosting accounts
Available on Windows and macOS

WindowsmacOS

Download NetDrive →

Free trial. Lifetime and subscription plans available.

Map Your Symptom to a Cause

Before touching any setting, identify which symptom you’re hitting:

Symptom	Most likely cause
”Authentication failed” immediately	Wrong username, password, or key not accepted
Hangs 30–60 seconds then times out	Wrong hostname or port; firewall blocking port 22
”Host key verification failed”	First connection to this host, or server fingerprint changed
Mounts briefly then drops	Server-side idle timeout or network instability

This post covers the first three. If your mount drops after sitting idle, the keepalive patterns in Fix Mount Disconnects After Sleep on macOS apply to SFTP as well.

Fix 1: Verify Credentials and Host Settings

Open NetDrive’s Drive Manager, select your SFTP drive, and click Edit. Check each field carefully:

Host — the server’s hostname or IP address, without any sftp:// prefix. NetDrive adds the protocol automatically. A trailing slash here breaks resolution.
Port — SFTP defaults to 22. If your server administrator moved SSH to a non-standard port (a common hardening measure), enter it explicitly. Connecting to port 22 when the server listens on 2222 produces a timeout, not an “authentication failed” message — it is frequently overlooked for that reason.
Username — case-sensitive. Admin and admin are different accounts on Linux systems.
Password — re-enter it even if the field looks populated. Saved credentials can silently go stale after a server-side password rotation.

NetDrive mount status panel showing current connection state and drive health

After updating any field, click Connect rather than just saving. NetDrive only validates credentials on an actual connection attempt, not on save.

Verifying the SFTP server IP address before connecting in NetDrive

Fix 2: SSH Key Format Issues

SSH key authentication is more secure than passwords, but NetDrive requires the private key in PEM format — RSA keys starting with -----BEGIN RSA PRIVATE KEY----- or ECDSA keys starting with -----BEGIN EC PRIVATE KEY-----. Modern OpenSSH versions generate keys in a newer format (-----BEGIN OPENSSH PRIVATE KEY-----) by default, which NetDrive does not accept.

To convert an OpenSSH-format key to PEM on the machine where the key was generated:

ssh-keygen -p -m PEM -f ~/.ssh/id_rsa

This rewrites the private key file in-place. Back it up before running this command.

In NetDrive’s SFTP drive settings:

Set Auth type to Key instead of Password.
Under Private key file, browse to the .pem private key file on your local machine.
If the key has a passphrase, enter it in Key passphrase.
Confirm the matching public key is already in ~/.ssh/authorized_keys on the remote server.

A quick server-side check: running ssh -v user@hostname from a terminal shows which authentication methods the server offers and which keys it accepts. Lines containing Offering public key and Server accepts key confirm the pairing is correct without any NetDrive involvement.

Fix 3: Stale Host Key Verification

When NetDrive connects to an SFTP host for the first time — or after the server’s SSH fingerprint changes due to a hardware replacement, OS reinstall, or IP address being reused — it may refuse to connect with a host-key error.

NetDrive stores accepted host keys in its internal known-hosts cache. To clear a stale entry:

In Drive Manager, select your SFTP drive and open Edit.
Find the Clear known hosts or Reset host key option in the advanced settings panel.
Reconnect. NetDrive will prompt you to accept the new fingerprint.

Before accepting a changed fingerprint, verify it independently by running ssh-keyscan -t rsa hostname from any machine that already has SSH access to the server, then compare the output to what NetDrive presents. Accepting an unexpected fingerprint on a production server is a meaningful security risk.

Verifying the port number for the SFTP server before connecting in NetDrive

Wrap-up

SFTP authentication failures in NetDrive almost always come down to credentials, key format, or host configuration rather than NetDrive itself. Work through the three fixes in order — credentials first, then key format, then the host-key cache — and you’ll isolate the cause within a few minutes. If none of them resolve the issue, enable verbose logging in NetDrive’s preferences and post the log to support.bdrive.com for further diagnosis.

— Tayson, NetDrive