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

231–240 of 276 posts

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

#231

Post by 9dev »

eqvinox wrote: post #144
9dev wrote: post #118

Earlier quoted context omitted.

> How would that even work? Do you open your browser, log in, and then somehow transfer the session into your ssh client in a terminal? Does the browser assimilate the terminal? That's pretty well covered in RFC8628 and doesn't even require a browser on the same device where the SSH client is running. > And let me remind you, HTTP authentication isn't a login form. It's the browser built-in "HTTP username + password"…

Everything you've said is true for web authentication, and almost nothing of what you said is true for HTTP authentication. This is HTTP authentication: https://httpd.apache.org/docs/2.4/mod/mod_auth_basic.html https://github.com/francoismichel/ssh3/blob/5b4b242db02a5cfb... https://www.iana.org/assignments/http-authschemes/http-auths... Note the OAuth listed there is OAuth 1.0. Support for "native" HTTP authenticatio…

No, that isn’t true. All parts of the OAuth dance are just means to end up with a Bearer token in the Authorization header, and I don’t see why the process of obtaining this token couldn’t involve a web browser?

Plus—HTTP auth isn’t limited to Basic, Digest, and Bearer schemes. There’s nothing stopping an implementation from adding a new scheme if necessary, and add it to the IANA registry.

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

#232

Post by jeffhuys »

esseph wrote: post #116
oefrha wrote: post #34

Earlier quoted context omitted.

The huge downside of mosh is it handles its own rendering and destroys the scrollback buffer. (Yes I know I can add tmux for a middle ground.) But it's still irrelevant here; specifically called out in README: > The keystroke latency in a running session is unchanged.

"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.

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

#233

Post by blueflow »

Telemakhos wrote: post #30
zenmac wrote: post #26

Earlier quoted context omitted.

Yeah we got those good old network ppl or their corporate (don't knows much about tech) overlord to thank for that. If you ever using wifi in the airport or even some hotel with work suite unit around the world, you will notice that Apple Mail can't send or receive emails. It is probably some company wide policy to first block port 25 (that is even the case with some hosting providers) all in the name of fighting SPA…

Port 25 is insecure and unencrypted; EU doesn't even need ChatControl to hoover up that data, and you'd better believe anything going through an airport wifi router unencrypted is being hoovered by someone no matter what jurisdiction you're in. Apple mail prefers 587 for secure SMTP and 993 for secure IMAP. People were (wisely) blocking port 25 twenty years ago.

Port 25, which you call insecure and unencrypted, is using the same protocol as port 587, which you call secure - SMTP with STARTTLS.

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

#234

Post by FergusArgyll »

This sounds cool, is there a way to do this with ssh?

  Similarly to your secret Google Drive documents, your SSH3 server can be 
  hidden behind a secret link and only answer to authentication attempts that
  made an HTTP request to this specific link, like the following:

  ssh3-server -bind 192.0.2.0:443 -url-path

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

#235

Post by ema »

FergusArgyll wrote: post #234

This sounds cool, is there a way to do this with ssh? Similarly to your secret Google Drive documents, your SSH3 server can be hidden behind a secret link and only answer to authentication attempts that made an HTTP request to this specific link, like the following: ssh3-server -bind 192.0.2.0:443 -url-path

One thing you can do is listen on a non-standard port.

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

#236

Post by FergusArgyll »

ema wrote: post #235
FergusArgyll wrote: post #234

This sounds cool, is there a way to do this with ssh? Similarly to your secret Google Drive documents, your SSH3 server can be hidden behind a secret link and only answer to authentication attempts that made an HTTP request to this specific link, like the following: ssh3-server -bind 192.0.2.0:443 -url-path

One thing you can do is listen on a non-standard port.

yeah, I'm not worried either way. Just wondering if anyone has a hack for that

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

#238

Post by Denvercoder9 »

eqvinox wrote: post #145
9dev wrote: post #112

Earlier quoted context omitted.

That, or the SSH client opens a separate connection to the authorization server and polls for the session state until the user has completed the process; that would be the device code grant, which would solve this scenario just fine.

You're both talking about web authentication, not HTTP authentication. cf. https://news.ycombinator.com/item?id=45399594

Only to obtain the token, the actual connection itself uses HTTP authentication (Bearer scheme).

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

#239

Post by rollcat »

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 pretty good network/service map, you'll probably have silent breakage somewhere.

I'm not saying CAs should be the future of SSH, but TOFU is certainly a problem at scale.

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

#240

Post by rollcat »

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…

> Which is why I ended up writing my own mini-ansible which instead runs a remote command executor which can be used to run commands remotely without the session cost.

HMU on my email. I've been working on/with this since 2016, and I'd love to discuss: https://github.com/rollcat/judo>

Post reply on HN