Drag-and-Drop SFTP Uploads in the CertLocker Browser Terminal
You are already in a browser shell and need to move one config file or diagnostic script onto the host. Opening a second client, finding the same route, and handling another credential is a lot of ceremony for one file.
The CertLocker browser terminal can now accept a file dragged from your desktop and upload it with SFTP to the shell's current directory. The destination is shown before the drop, transfer progress stays in the terminal window, and the upload uses the active token-controlled SSH route.
It is a small workflow change, but it removes an awkward gap. The browser terminal was useful for checking a service or making a quick change. As soon as you needed to move haproxy.cfg, a maintenance script, or a support bundle, you were back to a separate SFTP client or a copied scp command.
We did not want file upload to become an unscoped shortcut. So the feature follows the same token, host, bastion, expiry, user verification, and protocol decisions as the terminal session around it.
SFTP has to be granted on the token
SSH access does not automatically permit file upload. A host token needs the SFTP protocol before the browser accepts a dropped file. The same SFTP grant also covers normal SFTP clients and the SFTP transport used by current OpenSSH scp clients.
This matters for support and incident access. Someone who only needs to inspect logs can keep an SSH-only token. Someone who has to place a release artifact on one host can receive SSH and SFTP for a short window, without being handed a reusable host key or a broad VPN route.
The terminal tells you where the file will land
A browser drop target needs an unambiguous destination. Uploading to a hidden default such as the user's home directory would be easy to implement and annoying to operate. The terminal instead tracks the active POSIX working directory and shows it in the footer.
Where the remote shell emits an OSC 7 working-directory signal, the terminal reads it. It also follows ordinary cd commands. If the directory is still unknown when a file is dropped, the client asks the shell for pwd at the prompt. If CertLocker cannot resolve an absolute directory safely, it refuses the upload instead of guessing.
The destination changes with the directory you are in at the moment of the drop. For example:
cd /etc/haproxy
# Drop haproxy.cfg into the terminal
# Remote destination: /etc/haproxy/haproxy.cfg
Run cd /tmp first and the same file goes to /tmp/haproxy.cfg. Stay in /home/ops and it goes to /home/ops/haproxy.cfg, as shown in these screenshots. The remote user still needs write permission in whichever directory is current.
Dragging a file over the terminal makes that decision visible. The overlay states that SFTP will be used and prints the destination directory. Drop it, and the file's basename is appended to that directory. The server strips local path components from names such as C:\Users\ops\haproxy.cfg, normalizes the absolute destination directory, and writes the result as /home/ops/haproxy.cfg.
The file streams through the existing SSH session
After the drop, the browser sends a small control message containing the file name, current directory, and size. The edge opens an SFTP channel on the existing authenticated SSH client session. File bytes then move in chunks over the terminal WebSocket and are written to the remote SFTP handle.
The file is not added to the CertLocker secret store or kept as a new platform asset. CertLocker is the controlled route between the authenticated browser session and the target host. The terminal reports the remote path, bytes sent, total size, completion, and any error returned by the SFTP path.
Remote filesystem permissions still apply. If the authenticated remote user cannot write to the current directory, the upload fails. This feature does not turn a scoped terminal session into root access, and it does not bypass the target host's SFTP configuration.
The refusal paths are part of the feature
There are several cases where accepting a drop would be ambiguous or too broad, so the terminal stops early:
- An SSH-only token is denied because SFTP was not granted.
- Folders are skipped; the current flow uploads files only.
- A drop inside a full-screen terminal program is refused. Return to the shell prompt first.
- An unknown or non-absolute working directory is refused.
- Empty, traversal-style, control-character, and overlong file names are rejected.
- Files are uploaded sequentially, with one active SFTP upload at a time.
One more operational detail: uploading a file with the same name replaces the remote file. The server opens the destination for create, truncate, and write. Check the directory and file name before dropping a production configuration. This is a transfer tool, not a version-control system or deployment approval workflow.
What this is useful for
The good use cases are deliberately ordinary: moving a small config into a staging directory, placing a diagnostic script before an incident check, uploading a support bundle to the host an engineer is already working on, or getting one certificate-related file onto an awkward server without distributing another permanent credential.
It is not trying to replace rsync, a release pipeline, object storage, or a full remote file manager. For repeatable deployments, keep using automation. For the one-file job inside a short-lived browser session, drag and drop is now the shorter path.
Evaluation
Get started: book a hosted walkthrough to review token scoping, browser SSH, SFTP permission boundaries and the upload workflow with our engineers.
One-month onsite evaluation: deploy CertLocker into your own environment and test the path against the bastions, Linux hosts, support routes, private networks, and remote filesystem permissions your team actually has.
Hosted shows how the workflow behaves. Onsite proves whether it fits the awkward parts of your estate.