171–180 of 206 posts
This is cool, but calling that SSH3 is not appropriate. It's an independent project, not a new version of the SSH protocol. Sure, it's "SSH3" and not "SSHv3". Still, introducing a confusion with something that could be an official protocol is not nice.
Earlier quoted context omitted.
It's likely the URL can be discovered via basic timing attacks as virtually zero routers do constant-time comparisons for route matching.
If the URL path is meant to be kept secret, such as here, they should use a password hashing algorithm such as for example bcrypt or scrypt for the URL path and hash the path of every incoming request and then check the hash of the path instead of the path itself
Earlier quoted context omitted.
SSH Certs are not related to x509 PKI certs. SSH certs are created with ssh-keygen and is the result of one key signing another. The public portion of the signing key (ie. the “cert”) needs to be distributed separately.
Did you follow the link? The point was exactly setting up X.509 PKI for SSH authentication. Yes, it can be used with SSH, that was the GP's point.
> For our part, the most recent release of step & step-ca (v0.12.0) adds basic SSH certificate support. In other words:
> step-ca is now an SSH CA (in addition to being an X.509 CA)
> step makes it easy for users and hosts to get certificates from step-ca
It's a tool that do x509 ca for x509 things and ssh ca for ssh.
SSH over QUIC would be nice. I don't see any advantage of layering HTTP/3 here. It adds more friction, and the only advantage it brings is being able to "hide" the SSH server over a URL path. I guess x.509 certificates would be fine, but SSH hostkeys, SSHFP or TOFU is enough and far more secure (because it implicitly pins the server public key). It's a relatively new project from the looks of it, so I'd definitely no…
They list other advantages in the README such as tying into the web authentication model, which is pretty big for enterprise use as everything moves towards OIDC. If they could eventually use passkeys that’d be really nice.
People are being perhaps a little too over dramatic here. Yes, this is not SSHv3 as defined by a standards body. It is very much SSHv2 over HTTP/3. (Which sorta sounds like how HTTP/3 is actually HTTP/2 over QUIC) But there is lots of SSH servers and clients, such as Dropbear SSH, OpenSSH, libssh, libssh2 (which is very different from libssh which also supports sshv2), and more. So I don't blame the creators from put…
I think something like QSH (QUIC shell) might be a better name.
I believe security models for HTTP and SSH are pretty different. HTTP is usually public and anonymous, SSH is usually private and authenticated. While QUIC is definitely a great technology for HTTP use case, I'm not so sure about SSH. Not saying it's not, just it's something to reason about. For example x509 seems to be a disadvantage to me. I do not want anyone with a cheap DigiCert certificate be able to log in to…
SCNR, I know it's HN which is short for "Humor? No we don't understand humor".
Earlier quoted context omitted.
I think something like QSH (QUIC shell) might be a better name.
Quiche? (Or quissh)
Protecting against the potential for confusion from and/or abuses like this is what trademarks are for.