51–60 of 159 posts
This is my standard on new server setup (which is admittedly overkill but I'd rather have it slightly slower and safer): http://www.catb.org/esr/sshexport/ https://stribika.github.io/2015/01/04/secure-secure-shell.ht... SERVER SIDE: sources.list (if you're on an older version of debian) deb http://http.debian.net/debian wheezy-backports main apt-get -t wheezy-backports install --reinstall ssh ==== cd /etc/ssh rm ssh_…
Did 1083 RSA 2048 signing operations in 1017532us (1064.3 ops/sec)
Did 29000 RSA 2048 verify operations in 1016092us (28540.7 ops/sec)
Did 1440 RSA 2048 (3 prime, e=3) signing operations in 1016334us (1416.9 ops/sec)
Did 50000 RSA 2048 (3 prime, e=3) verify operations in 1014778us (49271.9 ops/sec)
Did 152 RSA 4096 signing operations in 1000271us (152.0 ops/sec)
Did 8974 RSA 4096 verify operations in 1076287us (8337.9 ops/sec)
...
Did 6720 Ed25519 key generation operations in 1029483us (6527.5 ops/sec)
Did 6832 Ed25519 signing operations in 1058007us (6457.4 ops/sec)
Did 3120 Ed25519 verify operations in 1053982us (2960.2 ops/sec)
(also don't look at these numbers purely as speed, but as CPU time spent)
Earlier quoted context omitted.
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.
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.
This is my standard on new server setup (which is admittedly overkill but I'd rather have it slightly slower and safer): http://www.catb.org/esr/sshexport/ https://stribika.github.io/2015/01/04/secure-secure-shell.ht... SERVER SIDE: sources.list (if you're on an older version of debian) deb http://http.debian.net/debian wheezy-backports main apt-get -t wheezy-backports install --reinstall ssh ==== cd /etc/ssh rm ssh_…
Earlier quoted context omitted.
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 unt…
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.
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?
RSA 2048 is still the openssh default, i.e., best current advice from the openssh authors. The fact that this article's author labels that as "yellow" is a red flag.
That is a concern for the DH key establishment though, that might be decrypted in future.
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?
There is absolutely no reason to pass arguments to ssh-keygen. If it is actually deemed necessary to do so, then that package's installation is inexcusably broken.