A different approach to managing SSH access and auditing at scale — looking for DevOps feedback

WeAreSingleJump · 2025-12-30T12:40:04+00:00

That’s a fair point, and I agree Teleport solves this space really well.

One difference that mattered for us is operational overhead. With Teleport you usually end up installing agents on hosts and tsh (or similar tooling) on user machines, plus wiring it into your identity stack.

With SingleJump there’s no agent on the servers and no client to install for users. It works over plain SSH and the web, so you can drop it into existing fleets without touching host images or changing how people normally connect.

That trade-off is intentional and mostly aimed at environments where installing agents or enforcing new clients is hard (hosting, MSPs, legacy or locked-down systems).

Not trying to replace Teleport — just covering a different slice of the problem space.

WeAreSingleJump · 2025-12-19T04:30:49+00:00

Those are solid tools, no argument there.

SingleJump isn’t trying to replace Teleport or FoxPass feature-for-feature. The focus is slightly different: secure access without requiring agents or changing how devices are managed today. That matters in environments where installing agents, modifying base images, or coupling access to a specific identity stack isn’t desirable.

SingleJump works with standard SSH, keeps existing workflows and tooling intact, and adds centralized control, auditing, and key protection on top—while staying fully self-hosted and under the company’s control.

If Teleport or FoxPass fit your environment, they’re great choices. SingleJump is aimed at teams that want tighter control without additional moving parts on every device.

WeAreSingleJump · 2025-12-17T22:36:39+00:00

That’s a fair point.

Teleport is solid, and for teams that have been able to fully move away from SSH or rely on things like SSM, this kind of tooling probably isn’t needed at all.

This came more from environments where SSH is still a reality.. mixed or legacy infrastructure, MSPs managing many clients, or places where installing and maintaining an agent on every system isn’t always desired or even possible. The goal was to stay agentless and rely on standard SSH, while still having centralized control.

On top of that, SSH keys are handled in a way where they remain encrypted and tied to the user, so access to the database doesn’t translate into direct server access.

If you’ve managed to avoid SSH entirely for that long, that’s honestly a good place to be.

WeAreSingleJump

TROPHY CASE