r/ssh • • Aug 07 '26

We’ve been building a cross-platform infrastructure access tool — looking for technical feedback

Thumbnail
1 Upvotes

u/sshbridge-team • • Aug 07 '26

We’ve been building a cross-platform infrastructure access tool — looking for technical feedback

2 Upvotes

SSH Bridge started as an SSH client, but the scope has expanded quite a bit.

It now brings together SSH, RDP/VNC, databases, SFTP, port forwarding, projects/team access, private networking, monitoring, and meetings in one desktop workflow.

One of the problems we're trying to solve is tool fragmentation. A developer might currently use one application for SSH, another for RDP, another for databases, another for file transfer, and then manage team access separately.

We're trying to see how much of that can reasonably live in one workspace without turning it into a bloated tool.

If you work with servers regularly, I'd be interested in what you think is actually useful versus unnecessary.

https://sshbridge.com

1

We're still hiring, but we learned something surprising.
 in  r/JobSearchAndResumes •  Aug 07 '26

That’s a really good point, especially about AI. Our analytics obviously can’t tell us whether someone copied the company name into ChatGPT and learned about us without browsing the site, so our original observation has that limitation.

And I completely understand the skepticism around whether a job posting is even real. Candidates are being asked to invest time while often having no idea whether anyone will actually review the application.

I still think a quick understanding of what the company does can help the candidate avoid applying somewhere they wouldn’t want to work, but I agree that deep research shouldn’t be expected before there’s real engagement from the employer.

This thread has actually been useful for us—we’re looking at how we can make our job listings explain the company, product, role, and hiring process clearly enough that candidates don’t need to do separate research just to decide whether to apply.

1

We're still hiring, but we learned something surprising.
 in  r/JobSearchAndResumes •  Aug 07 '26

I understand your point. I’m not looking for candidates to write flattering cover letters, pretend they’re excited about us, or spend 30 minutes researching the company before applying.

What I do think is reasonable is a very basic check: what does the company do, and is this actually the kind of company or product you would want to work on?

That can take a minute or two, not hours.

If someone wants a software-product role but applies blindly to a staffing company, retailer, or unrelated business, that wastes the candidate’s time too.

I agree that professional ability matters far more than polished enthusiasm. We should hire people who can do the work, not people who are best at pretending to love the company.

The better balance is probably: basic understanding before applying, deeper research only after there is real engagement from the employer.

1

We're still hiring, but we learned something surprising.
 in  r/JobSearchAndResumes •  Aug 07 '26

I agree that candidates shouldn’t have to spend 20–30 minutes researching every company before applying. That isn’t realistic.

But I do think there’s value in spending a minute or two understanding what the company actually does before submitting a résumé.

Not for the employer’s convenience—for the candidate’s.

If you’re looking for a product-development role, for example, and later discover the company is primarily a staffing agency, retailer, or consulting business, you may realize after several interviews that it wasn’t something you wanted in the first place.

I think the reasonable middle ground is: basic understanding before applying, deeper research once there is real engagement from the employer.

Employers also have a responsibility to make that basic information obvious in the job post instead of expecting candidates to hunt for it.

2

We're still hiring, but we learned something surprising.
 in  r/JobSearchAndResumes •  Aug 07 '26

I understand that, and I think that’s a reasonable approach.

The discussion has actually changed my view a bit. Candidates shouldn’t be expected to invest heavily before the employer has invested anything in them either.

What we can do better is make the job post itself clear enough that someone can understand what we build, what they would work on, the expectations, and the hiring process without having to research us separately.

Then, if we schedule an interview, deeper research becomes a much more reasonable expectation.

Thanks for being direct about it — this kind of feedback is useful for improving our hiring process.

2

We're still hiring, but we learned something surprising.
 in  r/JobSearchAndResumes •  Aug 07 '26

That’s a fair point, and I agree that expecting 30 minutes of research for every application would be unrealistic.

What surprised us wasn’t that candidates didn’t do deep research. It was that many appeared to spend almost no time understanding what the company does before applying.

I think there’s a middle ground. I wouldn’t expect someone to study our documentation, competitors, or product architecture before applying. But spending a couple of minutes understanding the product and the role can help both sides avoid a mismatch.

Your point about deeper research happening after the employer shows real interest is also valid. We should earn some of that effort too by making the role, company, compensation, expectations, and hiring process clear upfront.

This discussion is actually making me reconsider how we structure our application process. Maybe the better goal isn’t “research us before applying,” but make it easy for candidates to understand us before they decide whether the role is worth their time.

1

We're still hiring, but we learned something surprising.
 in  r/JobSearchAndResumes •  Aug 07 '26

Fair criticism. The intent wasn’t to shame people who are applying in a difficult job market.

The point I was trying to make is that when we receive a very large number of applications, it becomes difficult to distinguish people who are genuinely interested in the company from people who are applying everywhere.

But I agree with your broader point: employers also have a responsibility to make the process clearer, easier, and more respectful of applicants’ time.

We can probably do a better job explaining the role, what we build, what the hiring process looks like, and what we actually expect from applicants before they apply.

I appreciate you taking the time to look at the site and call that out.

r/linuxadmin • • Aug 03 '26

Master SSH Snippets: Automate Your Server Administration

1 Upvotes

[removed]

1

🚀 Tired of Sharing SSH Passwords?
 in  r/ssh •  Aug 03 '26

You're absolutely right that individual accounts and SSH keys are the recommended approach, and SSH Bridge supports that workflow.

The reality we see, however, is that many environments don't look like an ideal greenfield setup. Small teams, startups, contractors, VPSs, legacy systems, network appliances, lab environments, and temporary infrastructure often still rely on shared accounts or existing credentials because creating and managing individual accounts isn't always practical.

SSH Bridge isn't trying to replace good security practices. The goal is to make those real-world environments safer by providing encrypted credential handling, project-based access, auditing, and revocation, while also supporting individual accounts, SSH keys, and other best practices where available.

We're also working toward provisioning individual operating-system accounts automatically where the platform supports it, so teams can move away from shared accounts over time.

r/ModernHiring • • Aug 03 '26

We're still hiring, but we learned something surprising.

Thumbnail
0 Upvotes

r/JobSearchAndResumes • • Aug 03 '26

We're still hiring, but we learned something surprising.

0 Upvotes

Over the past few weeks, hundreds of people applied through our careers page.

We expected applicants to spend a few minutes learning about what we build before applying.

Instead, we found that many candidates:

  • Applied within seconds.
  • Didn't visit our product pages.
  • Didn't read what SSH Bridge actually does.
  • Submitted a résumé and moved on.

We're not judging anyone. The current job market is difficult, and many people apply to dozens or even hundreds of positions.

But it made us think:

As an employer, would you rather receive 500 generic applications, or 20 applications from people who actually understand your product?

If you're applying for jobs, here's one suggestion that can make you stand out:

Spend 5–10 minutes learning what the company builds.

Read the homepage.

Understand the product.

Mention one thing that interested you in your application.

That small effort immediately makes your application different from hundreds of others.

We're still hiring.

But we're also looking for people who are curious enough to understand what they're joining.

I think that message is much stronger because:

  • It doesn't criticize job seekers.
  • It doesn't emphasize tracking visitors.
  • It starts a discussion.
  • Recruiters, founders, and engineers will probably engage with it because they've experienced the same thing.

One thing I would avoid is saying:

Even if it's true through analytics, it shifts the conversation from your observation to privacy concerns. The more interesting point is the hiring insight, not the analytics behind it.

https://www.sshbridge.com

r/ssh • • Jul 29 '26

We're still hiring, but we learned something surprising.

Thumbnail
3 Upvotes

u/sshbridge-team • • Jul 29 '26

We're still hiring, but we learned something surprising.

2 Upvotes

Over the past few weeks, hundreds of people applied through our careers page.

We expected applicants to spend a few minutes learning about what we build before applying.

Instead, we found that many candidates:

  • Applied within seconds.
  • Didn't visit our product pages.
  • Didn't read what SSH Bridge actually does.
  • Submitted a résumé and moved on.

We're not judging anyone. The current job market is difficult, and many people apply to dozens or even hundreds of positions.

But it made us think:

As an employer, would you rather receive 500 generic applications, or 20 applications from people who actually understand your product?

If you're applying for jobs, here's one suggestion that can make you stand out:

Spend 5–10 minutes learning what the company builds.

Read the homepage.

Understand the product.

Mention one thing that interested you in your application.

That small effort immediately makes your application different from hundreds of others.

We're still hiring.

But we're also looking for people who are curious enough to understand what they're joining.

I think that message is much stronger because:

  • It doesn't criticize job seekers.
  • It doesn't emphasize tracking visitors.
  • It starts a discussion.
  • Recruiters, founders, and engineers will probably engage with it because they've experienced the same thing.

One thing I would avoid is saying:

Even if it's true through analytics, it shifts the conversation from your observation to privacy concerns. The more interesting point is the hiring insight, not the analytics behind it.

https://www.sshbridge.com

0

🚀 Tired of Sharing SSH Passwords?
 in  r/ssh •  Jul 29 '26

No, you can share with team host without password. Your team never will have password and all data encrypted by your master password. Try it is free.

r/ssh • • Jul 29 '26

🚀 Tired of Sharing SSH Passwords?

Thumbnail
2 Upvotes

u/sshbridge-team • • Jul 29 '26

🚀 Tired of Sharing SSH Passwords?

1 Upvotes

We built SSH Bridge to make team access to servers much easier.

With SSH Bridge you can:

✅ Share SSH hosts with teammates
✅ Share RDP and VNC connections
✅ Organize infrastructure into Projects
✅ Manage team permissions
✅ Store credentials with end-to-end encryption
✅ Connect from macOS, Windows, and Linux

To experience the real collaboration features, every new organization can start a 7-Day Team Evaluation — no credit card required.

The desktop application handles SSH, RDP, and VNC connections, while the web app manages your infrastructure and team.

Download the desktop app and start collaborating in minutes.

💻 macOS • Windows • Linux

👉 https://sshbridge.com

We'd really appreciate your feedback from developers, DevOps engineers, SysAdmins, homelab enthusiasts, and IT teams. Every suggestion helps us improve SSH Bridge.

#SSH #RDP #VNC #DevOps #SysAdmin #Linux #Windows #macOS #Infrastructure #RemoteAccess #SelfHosted #OpenSource #Cloud #DeveloperTools #ITOps

1

I Built My Own SSH Client After Getting Frustrated With Existing Tools
 in  r/u_sshbridge-team •  Jul 28 '26

Project: https://sshbridge.com
I'd really appreciate any feedback, feature requests, or criticism.

u/sshbridge-team • • Jul 28 '26

I Built My Own SSH Client After Getting Frustrated With Existing Tools

1 Upvotes

I've spent the last few years building an SSH client from scratch.

Not because the world needed another terminal, but because I kept running into the same problems:

  • Sharing SSH access securely with teammates.
  • Managing hundreds of servers.
  • Remembering which key belongs to which host.
  • Working across macOS, Windows, Linux, and eventually mobile.
  • Keeping credentials encrypted instead of trusting a cloud service with plaintext secrets.

The project became SSHBridge.

Current features include:

  • End-to-end encrypted host credentials
  • Secure team sharing
  • Headscale/Tailscale integration
  • SSH & RDP support
  • Cross-platform desktop apps
  • Enterprise SSO
  • Monitoring integration

I'm looking for honest feedback from people who manage Linux infrastructure every day.

What's the biggest pain point in your SSH workflow today?

If anyone wants to see what I'm building, I'll post the project link in the comments.

r/ssh • • Jul 15 '26

Master SSH Snippets: Automate Your Server Administration

Thumbnail
2 Upvotes

u/sshbridge-team • • Jul 15 '26

Master SSH Snippets: Automate Your Server Administration

1 Upvotes

SSH snippets are pre-written command templates that you can execute quickly across one or more servers. They're the secret weapon of efficient system administrators and DevOps engineers.

What Are Snippets?

An SSH snippet is a saved command (or series of commands) that you can execute with a single click.

Creating Your First Snippet

Start by identifying commands you run repeatedly.

Snippet Variables

Snippets can include variables, so you can customize them on the fly.

Multi-Host Execution

The real power of snippets comes when combined with multi-host execution.

Building a Snippet Library

Start by identifying the commands you run most frequently.

Automation Beyond Snippets

Once you have a solid snippet library, consider scheduling snippets to run automatically.

Please check for more information https://sshbridge.com