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
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
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.
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
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
Aren't ssh and mosh open-source or what does that mean?
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...".
I had the same thought. Probably bad phrasing, the author might not be a native English speaker.
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
Tangential feedback: As clever as it might be, the website made me pull back when opening and drilling in on mobile, quite disorienting.
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.
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.