For many teams, the entry point is not the server itself but a bastion such as JumpServer. SSH traffic passes through it, with auditing, authorization, and session recording handled there.
JumpServer’s browser-based terminal can get the job done, but a full day can reveal friction: copy and paste occasionally losing content, sessions disappearing after disconnection, a separate workflow for file transfers, and tabs and splits that feel different from a local terminal.
That is why I treated the JumpServer workflow as a first-class testing scenario early in Docklark’s development.
What to test first
The first task was not adding features. It was getting the basic path working. Earlier versions were tested on real devices for three things: connecting directly to a server over SSH, logging in through JumpServer, and reaching a target host behind the bastion. The experience only becomes worth discussing once those paths work.
Trade-off one: bind SFTP and monitoring to the entry connection
Docklark’s SFTP transfers and resource monitoring attach to the SSH entry connection: the SSH2 connection that the client actually authenticates and controls.
Following a nested session all the way to its final destination might look smarter, but I chose not to do that:
- Nested SSH and target changes inside a JumpServer asset menu happen in the remote shell. The client cannot reliably detect them.
- Trying to follow them means authenticating new connections repeatedly. When something fails, the user may not know which machine is actually being operated on.
- Staying on the entry connection lets SFTP and monitoring reuse the same authenticated connection, making the behavior predictable.
I would rather require an explicit choice than have the client guess. It is one of the design decisions I feel most confident about.
Trade-off two: isolated connection reuse with preflight checks
Each connection has its own short, 48-byte SSH multiplexing path. SFTP and monitoring share that authenticated connection. Before starting an auxiliary channel, the local multiplexing socket is checked: its path, directory, ownership, permissions, and existence, with distinct explanations for each failure.
Those checks are tedious, but path and permission problems are common in bastion environments. Explaining the actual failure is much more useful than displaying “Connection failed.”
Trade-off three: no silent fallback to reauthentication
If an auxiliary channel such as SFTP or monitoring fails to start, Docklark does not silently fall back to a new authentication attempt. That fallback can feel smoother in a test environment. In production, it can mean traffic taking an unexpected path, or a user believing there is one connection when there are actually two.
Instead, the failure stays visible in the window with an explanation. Refresh provides a way to retry. A little slower, but honest.
Still evolving
These decisions are still being refined as development continues. Follow the project page for Docklark’s progress and release status.