Mountain Duck SFTP: the second login after the VPN
The gateway and the file server authenticate different things. Use the SFTP administrator's hostname, answer its prompt, and keep the host key check.
The VPN connects, the menu bar shows a tunnel, and Mountain Duck still asks for a login. Then it asks for a code. Nothing is broken: two different systems are authenticating you, and the second one has never heard of the first. The VPN's MFA proves something to the gateway. The SFTP server asks for its own proof, against its own account.
Two prompts, two systems
The gateway and the file server are separate policy domains. They may share a directory, or they may have nothing in common but the person using them. Passing a one-time code at the VPN does not create a session on the SFTP host, and the SFTP host cannot tell whether you used a tunnel at all. Each system believes it is the only one asking.
| Layer | What it authenticates | Where the account lives |
|---|---|---|
| VPN | The tunnel endpoint | Gateway or identity provider |
| SFTP | The file session | SSH server or its directory |
| Folder access | Read and write within the share | Filesystem permissions |
Treat the three as separate rows in your notes. When one fails, the row tells you which console to open, and that is most of the work.
Use the SFTP administrator's address
A bookmark needs the hostname and port the file service actually listens on, which is not necessarily the VPN server's address. Ask the administrator who runs the SFTP service, and use the same hostname other clients use.
Keep the server-identity check intact. Mountain Duck and Cyberduck show the host key on first connection, and comparing it against a value the administrator supplies out of band is the step that stops a wrong server from receiving your credentials. Disabling that check to make a bookmark connect is a permanent decision disguised as a convenience. It also removes the only evidence you would have afterwards that the file went where you intended.
Answer the challenge the server sends
The project's SFTP documentation describes challenge-response support for one-time passcodes: an initial login prompt, then a second prompt for the code, as the server requests it. The flow belongs to the server's configuration, and a client cannot add server-side two-factor enforcement by storing another value in its password field.
So the bookmark should hold the ordinary account credential, and the code should be typed when the prompt appears. Saving a changing code as the permanent password produces a bookmark that works once, then fails in a way that looks like a wrong password. Putting the code into the VPN credential field fails differently: the gateway rejects it, and the tunnel never comes up. Two prompts, two places, and swapping them breaks both.
Automatic mounting cannot press a button
If the bookmark reconnects in the background, an interactive challenge has nobody to answer it. The mount retries, the server asks again, and the log fills with attempts that cannot succeed. That is the honest result of a policy that requires a person.
Plan for the interaction: connect the tunnel and the bookmark while you are present, then treat later automatic reconnects as best-effort. If the workflow genuinely needs unattended access, the server owner has to approve a different authentication arrangement, which is a policy change rather than a bookmark setting.
A mount is not a permission
A mounted volume proves that a session authenticated. It does not prove that the account may write everywhere on that server. Check the intended folder, try the operation you actually need, and confirm the result from the server side when the answer matters. The Finder sidebar shows a volume; it says nothing about the permissions behind it.
For a different protocol, use that provider's documented authentication method rather than copying this sequence. A cloud sign-in and an SSH challenge can look identical in the sidebar and behave nothing alike underneath.