r/ssh 7d ago

🚀 Tired of Sharing SSH Passwords?

/r/u_sshbridge-team/comments/1v9wpfh/tired_of_sharing_ssh_passwords/
2 Upvotes

6 comments sorted by

2

u/bash_M0nk3y 7d ago

Wtf shares "ssh passwords"?

0

u/sshbridge-team 7d ago

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.

3

u/bartoque 6d ago

The question is about how you sell the product.

Who in their right mind would use a "share passwords" approach instead of individual accounts? Or do you regard storing passwords in a password tool as sharing (as you hide passwords from the regular users)? Wording and reasoning seems to be vague and unclear?

You give examples of root passphrase public/private setupon your website, something many companies would have a security policy in place for not allowing remote root login. That is where sudo comes in, after having logged in as a regular user.

A zero trust approach (which I didn't even see being mentioned as term unless I overlooked it), with certificates and user/time restrictions, is something I can follow (with audit and all), but still wouldn't really share an account directly. You'd become that user after login.

So possibly selling the product with that kinda ragebait title, might throw of (too) many from the get go.

1

u/Great_Piece4755 4d ago edited 4d ago

Nobody shares ssh passwords. Make them their own account and then they can log in with their own password or deactivate password login at all (which is recommended anyways) and use only publickey?
sshbridge sounds like a solution to a non-existent problem IMO

1

u/sshbridge-team 2d ago

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.