Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SSH3: Faster and rich secure shell using HTTP/3

github.com

Post reply on HN
Print view View original

251–260 of 276 posts

Re: SSH3: Faster and rich secure shell using HTTP/3

#251

Post by fsckboy »

zamadatix wrote: post #184
voxadam wrote: post #177

Earlier quoted context omitted.

Is it dead or just mature?

Mature should still be fixing bugs, which something like mosh is bound to always run into. From that perspective, it doesn't seem like it's just mature. There doesn't seem to be a clear all-in-one successor fork taking the reins either. E.g. https://github.com/mobile-shell/mosh/issues/1339 , as a random sample.

mosh is still included in the Fedora repository (and probably others, I didn't check)

major distros are maintained, and they wouldn't be shipping it if it had bugs and/or was being used as an exploit

Re: SSH3: Faster and rich secure shell using HTTP/3

#252

Post by fsckboy »

psanford wrote: post #19

I do hate the name ssh3. I was glad to see this at the top of the repo: > SSH3 is probably going to change its name. It is still the SSH Connection Protocol (RFC4254) running on top of HTTP/3 Extended connect, but the required changes are heavy and too distant from the philosophy of popular SSH implementations to be considered for integration. The specification draft has already been renamed ("Remote Terminals over H…

my autism plays out also in the world of words, i.e. names of things, and my comment here is more a reply to all my surrounding comments than to yours:

ssh is not a shell and ssh is not a terminal, so please everybody stop suggesting name improvements that more deeply embed that confusion.

back in the day, we had actual terminals, and running inside was our shell which was sh. then there was also csh. then there was the idea of "remote" so rsh from your $SHELL would give you a remote $SHELL on another machine. rsh was not a shell, and it was not a terminal. There were a whole bunch of r- prefixed commands, it was a family, and nobody was confused, these tools were not the thing after the r-, these tools were just the r- part.

then it was realized that open protocols were too insecure so all of the r- remote tools became s- secure remote tools.

http is a network protocol that enables other things and gets updated from time to time, and it is not html or css, or javascript; so is ssh a network protocol, and as I said, not a shell and not a terminal.

just try to keep it in mind when thinking of new names for new variants.

and if somebody wants to reply that tcp/ip is actually the network protocol, that's great, more clarification is always good, just don't lose sight of the ball.

Re: SSH3: Faster and rich secure shell using HTTP/3

#253

Post by Aachen »

zielmicha wrote: post #243
Zambyte wrote: post #2

I was skeptical of the claim that it's faster than traditional SSH, but the README specifies that it is faster at establishing a connection, and that active connections are the same speed. That makes a lot of sense and seems like a reasonable claim to make.

SSH is actually really slow on high latency high bandwidth links (this is what HPN-SSH patches fix: https://www.psc.edu/hpn-ssh-home/hpn-ssh-faq ). It's very apparent if you try running rsync between two datacenters on different contients. HTTP/3 (and hopefully this project) does not have this problem.

Sounds like a complex change to fix a security protocol but, reading the page, it seems to just increase the send buffer, which indeed makes sense for high-latency links

Re: SSH3: Faster and rich secure shell using HTTP/3

#254

Post by codedokode »

doublerabbit wrote: post #166
codedokode wrote: post #162

Earlier quoted context omitted.

This is actually good because every protocol ideally must look the same to make traffic shaping and censorship harder. Either random stream of bytes or HTTP. If you are designing a protocol, unless you have a secret deal with telcos, I suggest you masquerade it as something like HTTP so that it is more difficult to slow down your traffic.

It's been known they throttle HTTP too. So your super speedy HTTP SSH connection then ends up being slower than if you just used ssh. Especially if your http traffic looks rogue. At least when its its own protocol you can come up with strategies to work around the censorship.

No. If you masquerade as HTTPS you can set your SNI to trump.example.com or republicans.example.com and nobody would dare to slow down this traffic. If you have a custom, detectable protocol then you already lost the game.

There is not only censorship, but traffic shaping when some apps are given a slow lane to speed up other apps. By making your protocol identifiable you gain nothing good.

Re: SSH3: Faster and rich secure shell using HTTP/3

#255

Post by zamadatix »

fsckboy wrote: post #251
zamadatix wrote: post #184

Earlier quoted context omitted.

Mature should still be fixing bugs, which something like mosh is bound to always run into. From that perspective, it doesn't seem like it's just mature. There doesn't seem to be a clear all-in-one successor fork taking the reins either. E.g. https://github.com/mobile-shell/mosh/issues/1339 , as a random sample.

mosh is still included in the Fedora repository (and probably others, I didn't check) major distros are maintained, and they wouldn't be shipping it if it had bugs and/or was being used as an exploit

Each distro package maintainer is always welcome to maintain patches in their forks for as long as they like, but the quality and life of each will be per distro as these efforts are coordinated with an upstream.

Re: SSH3: Faster and rich secure shell using HTTP/3

#256

Post by kbolino »

t-3 wrote: post #58
kbolino wrote: post #48

Earlier quoted context omitted.

Is there a way to configure the jump (hop) server to reroute the request based on the value of %h and/or %p? Otherwise, it's going to be quite difficult to configure something like HTTP virtual hosts. EDIT: Looking at the relevant RFC [1] and the OpenSSH sshd_config manual [2], it looks like the answer is that the protocol supports having the jump server decide what to do with the host/port information, but the OpenS…

Yes, but it's not in the sshd config, it's in the ssh config. See ssh_config(5), search for Remote to find the most relevant sections.

I don't follow. If it's in ssh_config, then it's client-side. Either that's the client initiating the request, in which case it's not server-controlled like HTTP virtual hosts, or else it's the "client" involved in the hop through the jump server, in which case it's going to be specific to a single username. Also the Remote* options have to do with remote port forwarding, which is in the wrong direction.

What am I missing?

Re: SSH3: Faster and rich secure shell using HTTP/3

#257

Post by Arch-TK »

nasretdinov wrote: post #218
Arch-TK wrote: post #179

SSH is slow, but in my experience the primary cause of slowdown is session setup. Be it PAM, or whatever OpenBSD is doing, the session setup kills performance, whether you're re-using the SSH connection or not, every time you start something within that connection. Now obviously for long running stuff, that doesn't matter as much as the total overhead. But if you're doing long running ssh you're probably using SSH fo…

To speed up Ansible it's sufficient to enable ControlMaster with a short timeout tbh

I don't believe control master solves the problem, as long as Ansible is configured to create a new session within the long-running SSH connection then it will still have the session setup overhead. I tested this myself when prototyping the replacement.

However, it looks like pipelining (and obviously forking) could do a lot to help.

That being said, there were _many_ reasons for me to drop Ansible. Including poor non-linux host support, Yaml, the weird hoops you have to jump through to make a module, and difficulty achieving certain results given the abstraction choices.

I think Ansible is great, it solves a problem, but my problem was very specific, Ansible was a poor fit for it, and performance was just one of many nails in the coffin for me.

Re: SSH3: Faster and rich secure shell using HTTP/3

#258

Post by superkuh »

rollcat wrote: post #239
superkuh wrote: post #195

So does this mean that you can't self sign anything and have to involve corporate CAs for your ssh now? Because QUIC cannot do anything without CA TLS approval being involved.

That is my main objection as well, but perhaps it's time to also revisit TOFU. Remember when Github had to rotate its host keys? It was hitting the news far and wide, and likely broke pretty close to every single CI pipeline out there. There was little heads up because it's the friggin host key, you have to act now . It's also pretty annoying when you have to deal with that in your own infra. Even if you have a prett…

Some day very soon everyone is going to get some uncomfortable lived experience showing just how dangerous and damaging putting all of our communications eggs in a handful of easily controlled corporate baskets is. It's now calvinball out there and distributed, not centralized, solutions are going to be required to route around the damage. The people who lived through it last time made the internet. And now that they're mostly retired or dead we're removing all the robustness they built in just to better align with employers' profit-motive use cases.

But we don't have to do that. Not on our own time. Don't use QUIC unless you're getting paid to do it.

Re: SSH3: Faster and rich secure shell using HTTP/3

#259

Post by esseph »

oefrha wrote: post #172
esseph wrote: post #116

Earlier quoted context omitted.

"huge downside" (completely mitigated by using tmux) The YouTube and social media eras made everyone so damn dramatic. :/ Mosh solves a problem. tmux provides a "solution" for some that resolves a design decision that can impact some user workflows. I guess what I'm saying here, is it you NEED mosh, then running tmux is not even a hard ask.

No it’s not completely mitigated by tmux. mosh has two main use cases (that I know of) 1. High latency, maybe even packet-dropping connections; 2. You’re roaming and don’t want to get disconnected all the time. For 2, sure tmux is mostly okay, it’s not as versatile as the native buffer if you use a good terminal emulator but whatever. For 1, using tmux in mosh gives you an awful, high latency scrollback buffer compar…

I believe this depends on the intent of your connection!. The first sentence of your last paragraph: "For read-heavy, reconnectable workloads" - A-ha!

From my stance, and where I've used mosh has been in performing quick actions on routers and servers that may have bad connections to them, or may be under DDoS, etc. "Read" is extremely limited.

So from that perspective and use case, the "huge downside" has never been a problem.

Re: SSH3: Faster and rich secure shell using HTTP/3

#260

Post by esseph »

jeffhuys wrote: post #232
esseph wrote: post #116

Earlier quoted context omitted.

"huge downside" (completely mitigated by using tmux) The YouTube and social media eras made everyone so damn dramatic. :/ Mosh solves a problem. tmux provides a "solution" for some that resolves a design decision that can impact some user workflows. I guess what I'm saying here, is it you NEED mosh, then running tmux is not even a hard ask.

Honestly, it feels like the one being dramatic here is you. Because the one you’re replying to added “huge”, you added a whole sentence calling everyone “so damn dramatic”. But oh well.

You know what has a "huge downside"? Radiation therapy.

Not a scroll back buffer workflow issue.

Post reply on HN