191–200 of 206 posts
Earlier quoted context omitted.
SSH certificates (I encourage using them!) are not x509, absolutely incompatible.
You're thinking of SSH keys, which are not certificates. SSH certificates are indeed x.509: https://datatracker.ietf.org/doc/html/rfc6187
Here is the description of file format, it's nothing like x509
https://github.com/openssh/openssh-portable/blob/master/PROT...
Earlier quoted context omitted.
SSH certificates (I encourage using them!) are not x509, absolutely incompatible.
It’s same general principle and same security model just different way of going about it. It supports CAs and extensions just like x509
For faster session establishment in OpenSSH consider ControlMaster in ssh_config(5), which multiplexes multiple sessions in one connection instead of creating a new connection for each session.
# ~/.ssh/config # Place at the *End-of-file* Host * ControlMaster auto ControlPath ~/.ssh/sockets/%C.sock ControlPersist 600 ServerAliveInterval 60 ServerAliveCountMax 10 IPQoS throughput TCPKeepAlive yes # :: Security Exception :: Purposeful for UX usability of machine-to-machine hops ForwardAgent yes # ssh-audit recommendations https://www.ssh-audit.com/hardening_guides.html # CASignatureAlgorithms sk-ssh-ed25519@o…
Earlier quoted context omitted.
SSH supports passkeys: https://developers.yubico.com/SSH/#_fido2
With hardware tokens, yes, I use that. I was thinking that building it on a web server would be really handy with an integrated client you could use with iCloud, Windows Hello, etc.
The difference is not just philosophical, it also has practical implications, in particular what part of the different protocols (SSH, HTTP, TLS and QUIC) clients, servers and intermediates are expected to implement and which can be left out.
E.g., if it's "SSH-over-HTTP", I'd expect the protocol to work well with HTTP proxies and application servers and I'd expect to be able to run a SSH3 server and a regular HTTP server on the same port. On the other hand, I'd expect features that require precise control over the low-level QUIC connection - like UDP port forwarding and session resumption - to be less reliable.
If it's "SSH-over-QUIC", the expectations would be the opposite: That you can treat QUIC (and TLS) as an integral part of the protocol, in the same way that the encryption, auth and transport layers in standard SSH are seen as an integral part of SSH. However then the server should generally be deployed as a standalone process on a separate port and should not be considered a fully compatible HTTP endpoint. That might diminish the "stealth" ability of the protocol a bit.
Or to sum it up, which parts of the protocol stack would an SSH3 client or server be expected to provide by themselves and which parts would be delegated to the OS/infrastructure/intermediaries etc?
Earlier quoted context omitted.
With hardware tokens, yes, I use that. I was thinking that building it on a web server would be really handy with an integrated client you could use with iCloud, Windows Hello, etc.
With /passkeys/, actually! It's more generic than just hardware keys. I don't know of any good implementation yet, but there were a few projects on github mentioned in some passkey-related discussions here. I do not use anything like iCloud or Windows Hello and I don't know what these services actually use, but if they implement these open standards, it's only a matter of adding some glue code. I'd say it's likely th…
Some searching suggests there’s at least one implementation of the SSH agent protocol using Windows Hello, which is great.
I know this isn't an actual v3 of the SSH protocol, but if there ever is a version 3 of SSH, it really needs some kind of (encrypted) SNI or at least a standardized metadata block that can be passed to any jumphost without having the know the specifics of the ProxyCommand on that middlebox.
SNI is absolutely needed. Over at https://pico.sh we have to request an IP for each ssh server even though from a resource perspective we really only need 1 VM. It increases the complexity of our deployments and overall makes us want to figure out how to merge all of our SSH apps into one.
Why is there http/3 in the middle? SSH over QUIC makes a lot of sense and was something I thought about before. The SSH protocol is designed to multiplex many “channels” over an encrypted tcp socket. Over each channel you can run things like a shell or SFTP. It would need some engineering but you could keep the same SSH features but replace the multiplexing channels over tcp with QUIC channels over udp. Where does HT…
You can use HTTP for authentication.
Earlier quoted context omitted.
Why are people obsessed with implanting CloudFlare right in the middle of everything they do? There is absolutely nobody that needs DDoS for their SSH server. I get that CloudFlare has been a well behaved netizen so far, but let's be real, it won't last forever. It never does. Eventually the shareholders start turning the screws and CloudFlare is going to succumb to the same pressures every company does and they're g…
Every personal blog is low traffic until it lands at the top of HN
Earlier quoted context omitted.
It's crazy that SSHFP hasn't taken off, I don't think a single person on earth has ever verified a host key before attempting to connect, and deploying DNSSEC is trivial now that you can use ECC and ED25519.
* Deploying DNSSEC is obviously not trivial, as doing so has taken some of the largest companies on the Internet fully off the Internet for multiple hours, within the last year, so much so that it has become a running joke when companies have prolonged outages to suggest that DNSSEC is the culprit. * There are still resolvers that can't handle Ed25519 * Being able to use Ed25519 was never the ops problem with getting…