It means that Osewa is open-source. I suppose that its possible for SSH alternatives to exist that are not open-source, which is why its worded as "An open-source alternative to...".
no- native speaker here (Spanish mother tongue), I read it as "an alternative, that is open source, to ...", no implication that the other options are not open source
A lot of things here look directionally right, like using QUIC and separating session from connection. However as others said the security implications of this make it almost unusable for production systems. It’s also unclear how often bad connection and roaming is a problem for real world usage. On the session side I think applications like Rex from Superlogical are going to build similar functionality on existing protocols
One of the main features of mosh is that it keeps local tty state and can do state transfer and update with the remote pty. This lets the user continue to type and see a (local) echo even when transport is lost. A mosh comparison on typing latency benchmark is notably missing and this entire feature goes unmentioned.
The limitation of SSH and Mosh are real, and SSH over Quic is not a novel idea but a good one. But SSH is a *highly critical* piece of software. A security issue in SSH is basically like giving the keys to the whole kingdom. In such a critical environment, I highly doubt a slop-coded "SSH but on Quic" will be well received. And you can already do that with Iroh and dumbpipe minus the slop code.
I think it’s really interesting that at the same time postgres is delayed because agents are finding so many more vulnerabilities than normal reviewers, we have people crying that the same code those agents review is slop.
There is a big difference between having agent review a codebase that several people know very well and have a good understanding of, and a vibecoded project where knowledge of the codebase is basically nil. This is especially true for safety critical software where oversight in the codebase can have dramatic consequence. How can a contributor fix a vulnerable subsystem if he does not even know that the subsystem exist ? This means being entirely reliant on agent to be able to find those flaws and to code without them.
Here's the github: https://github.com/rjyo/osewa
every commit has claude as an author (judge as you may)
Security:
> Where ssh is ahead is age: OpenSSH has decades of audits and osewa has none yet,
I think this is most important when concerning remote connections to your computer. though, that doesn't mean we should never improve.
> vibe-coded SSH
What's the use case? Because the existing SSH doesn't have enough exploits and security holes?
Another name to put on the industry blacklist, thanks
Tangential feedback: As clever as it might be, the website made me pull back when opening and drilling in on mobile, quite disorienting.
Aren't ssh and mosh open-source or what does that mean?
I had the same thought. Probably bad phrasing, the author might not be a native English speaker.
It means that Osewa is open-source. I suppose that its possible for SSH alternatives to exist that are not open-source, which is why its worded as "An open-source alternative to...".
no- native speaker here (Spanish mother tongue), I read it as "an alternative, that is open source, to ...", no implication that the other options are not open source
Why not throw these tokens at finding bugs in mosh rather than vibecoding something that nobody with sense will use? I don’t get it.
I usually don’t like to be a drive-by hater on projects that people post here, but a vibecoded SSH is irresponsible.
A lot of things here look directionally right, like using QUIC and separating session from connection. However as others said the security implications of this make it almost unusable for production systems. It’s also unclear how often bad connection and roaming is a problem for real world usage. On the session side I think applications like Rex from Superlogical are going to build similar functionality on existing protocols
One of the main features of mosh is that it keeps local tty state and can do state transfer and update with the remote pty. This lets the user continue to type and see a (local) echo even when transport is lost. A mosh comparison on typing latency benchmark is notably missing and this entire feature goes unmentioned.
Finally an open source alternative to ssh
The limitation of SSH and Mosh are real, and SSH over Quic is not a novel idea but a good one. But SSH is a *highly critical* piece of software. A security issue in SSH is basically like giving the keys to the whole kingdom. In such a critical environment, I highly doubt a slop-coded "SSH but on Quic" will be well received. And you can already do that with Iroh and dumbpipe minus the slop code.
I think it’s really interesting that at the same time postgres is delayed because agents are finding so many more vulnerabilities than normal reviewers, we have people crying that the same code those agents review is slop.
There is a big difference between having agent review a codebase that several people know very well and have a good understanding of, and a vibecoded project where knowledge of the codebase is basically nil. This is especially true for safety critical software where oversight in the codebase can have dramatic consequence. How can a contributor fix a vulnerable subsystem if he does not even know that the subsystem exist ? This means being entirely reliant on agent to be able to find those flaws and to code without them.
Something as essential to security like ssh should probably not be reinvented as AI slop like this for most if not all use-cases.
But it's written in Rust so it's all safe. /s
As an aside: it looks like they really are trying replace everything on the stack with Rust variants.