Hacker News Reader

Comment by Achshar | Hacker News Reader

Noob question here, why move just one step ahead. Why not 8192 or hell 16,384? I can see it can lead to higher CPU consumption on often used keys but for keys that are not accessed more than a couple of times a day, why is it such a bad idea to overdo it?

View on HN

Diminishing returns. Here is what GnuPG says about it https://www.gnupg.org/faq/gnupg-faq.html#no_default_of_rsa40...

I have multiple RSA keys of various lengths for servers that don't support my Ed25519 key (some cloud services sadly limit key length AND require RSA, despite their underlying ssh server actually supporting better). I routinely use 16384 bit RSA keys daily and have never had a noticeable performance impact. Sure, there's clearly the diminishing returns argument, but as there would be no impact for most folks why not?

In software just because isn't sufficient justification.

4096+ is noticeably slower.

someone correct me if i'm wrong, but I believe its not just used once a day. Its used for every packet you send while connected.

Those keys are used at the beginning of each connection, primarily to authenticate and negotiate a session key. The session key is then used for every packet.

I'm pretty sure you're wrong. These asymmetric crypto keys, with which it takes a long time to encode/decode, are used only at handshake to securely negotiate a per-session key that's used in symmetric crypto, for which encoding and decoding is extremely fast.

I am indeed mistaken, thanks!

The ssh protocol specs are actually quite readable. No, the slow asymmetric key is only used once to derive a fast symmetric key for the session. If you a set up a control master, then repeated logins to the same server (within some narrow window) will all multiplex over the same channel, too.

For those who have never heard of ControlMasters, I highly recommend them. SSH can multiplex multiple sessions (you invoking ssh at the terminal) over a single TCP socket — this feature is called ControlMaster. The first ssh command takes the normal amount of time, but every command after that is just ~a round-trip. No slow asymmetric key exchange. If you close all your connections, there a (configurable) timeout until the ControlMaster's connection closes.

You can combine this fact with zsh's autocomplete powers, and get pretty-close-to-instant (on a good connection) tab-completion of directories on the remote server, which is extremely nice when trying to scp something, as you can tab complete the paths in that command.

(It also saves a few PIDs on the server, as a single sshd child deals with all your connections.)

> You can combine this fact with zsh's autocomplete powers,

I found that recent versions of SSH have begun hashing `~/.ssh/known_hosts` which nerfed zsh autocomplete pretty badly. You need to set "HashKnownHosts no" in `~/.ssh/config`. The SSH change was made to prevent a key compromise from giving an attacker a ready-made list of vulnerable next targets.

But can't they also just find the hosts by looking at your bash history?

Bash history rotates (or can be managed, which a lot of people do), whereas known_hosts will have every server you ever accessed and is rarely ever touched.

Reply on news.ycombinator.com