4 ms·

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 t

• loeg 10y ago
  4096+ is noticeably slower.
• karmajunkie 10y ago
  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.
  • warkdarrior 10y ago
    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.
  • cscheid 10y ago
    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.
    • karmajunkie 10y ago
      I am indeed mistaken, thanks!
  • brandmeyer 10y ago
    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.
    • deathanatos 10y ago
      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.)
      • Steltek 10y ago
        > 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.
        • andromeduck 10y ago
          But can't they also just find the hosts by looking at your bash history?
          • toyg 10y ago
            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.
• rrego 10y ago
  Diminishing returns. Here is what GnuPG says about it https://www.gnupg.org/faq/gnupg-faq.html#no_default_of_rsa4096 https://www.gnupg.org/faq/gnupg-faq.html#no_default_of_rsa40...
• jsjohnst 10y ago
  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?
  • notyourwork 10y ago
    In software just because isn't sufficient justification.