[gsu2]

This seems bad?

- SSH3 is a bad name: this isn't a successor to SSHv2 and will only cause confusion

- The authors don't seem to understand that SSHv2 predates all of their chosen technologies, and provides "robust and time-tested mechanisms" they claim to be adding

- How is "hiding your server behind a secret link" a feature? This is, at best, security through obscurity, which can be layered on any network protocol (e.g. https://en.wikipedia.org/wiki/Port_knocking); this implies that the authors don't have much of a security background...?

- ...Which explains why they think something as complicated as OpenID Connect is a good thing to add to SSH (i.e. https://security.stackexchange.com/questions/148292/why-is-o...)

- The abstract in the linked paper seems to conflate SSHv1 and SSHv2; I couldn't really bring myself to read much past that

In summary: this seems bad.

[janosdebugs]

I concur. They seem to have reinvented a part of the protocol without actually addressing many of the issues of SSH. The paper also doesn't bother to go into details on any the advancements that have been made to SSH since the original RFC, such as keyboard-interactive, GSSAPI, etc.

> Some SSH implementations such as OpenSSH or Tectia support other ways to authenticate users. Among them is the certificate-based user authentication: only users in possession of a certificate signed by a trusted certificate authority (CA) can gain access to the remote server [12]. Available for more than 10 years, this authentication method requires setting up a CA and distributing the certificates to new users and is still not commonly used nowadays.

Somebody had an agenda to make SSH look as bad as possible. You can implement OIDC authentication with keyboard-interactive, no need for HTTP/3 for that. However, it gets very tricky if you want automated / script access, so it doesn't solve the authentication problem.

As an aside, Tatu Ylonen, the original author of the SSH protocol, published a paper in 2019 titled "SSH Key Management Challenges and Requirements"[1], which is an interesting read. It would seem the authors of this paper should have at least read it.

[1] https://www.ylonen.org/papers/ssh-key-challenges.pdf

[insanitybit]

> This is, at best, security through obscurity, which can be layered on any network protocol (e.g. https://en.wikipedia.org/wiki/Port_knocking); this implies that the authors don't have much of a security background...?

This isn't security through obscurity. The url would be a secret. This is a form of capability security, where to connect to the server you must be able to name the server.

A URL with a secret is, in my opinion, far more sane than port knocking, and will be much more efficient as well.

> (i.e. https://security.stackexchange.com/questions/148292/why-is-o...)

Your link doesn't support your statement at all. No one there answers "here's why oid is less secure", they say the opposite.

[_8j50]

Your points are great but SSH is extensible so openid connect support doesn't mean much since you can do it with existing ssh.

"Security by obscurity" is only a thing if you're relying on that mechanism for security. People already configure SSH port knocking as you noted. It can be considered attack surface reduction and is a good feature given they're not using a secret link for any security control.

One benefit of their approach might be how you can use TLS pki now instead if setting up ssh-ca's. Potentially you would need to manage less pki.

But a criticism I have is how http* has much more vulns and new attack techniques being developed all the time unlike ssh. I can imagine LFI or request smuggling on the same http/2 web server causing RCE via their protocol.

[idlephysicist]

I'd agree with you. The readme calls out "Significantly faster session establishment" and goes into greater detail later on.

> Establishing a new session with SSHv2 can take 5 to 7 network round-trip times, which can easily be noticed by the user. SSH3 only needs 3 round-trip times. The keystroke latency in a running session is unchanged.

I, for one, can say that sometimes session establishment can take a little while but not to the extent that it would be a selling point (so to speak) for me to adopt SSH3.

[markhahn]

ssh is fairly often used non-interactively.

so if you want to execute uptime on a remote machine, the session will only be open for a few ms, and those extra RTT are a problem. (Yes, I know about openssh controlmaster...)

[commandersaki]

SSH over HTTP/(url) is a killer feature if you're working on hostile networks that block SSH and go even as far as to try and detect the protocol over the wire.