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?
Upgrade your SSH keys
41–50 of 159 posts
Re: Upgrade your SSH keys
#42Noob 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?
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.
Re: Upgrade your SSH keys
#43This 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_host_key
ssh-keygen -t ed25519 -f ssh_host_ed25519_key -a 256 ssh-keygen -t rsa -b 4096 -f ssh_host_rsa_key (do not password protect server side keys)
====
/etc/ssh/sshd_config
Protocol 2
HostKey /etc/ssh/ssh_host_ed25519_key
HostKey /etc/ssh/ssh_host_rsa_key
KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-ripemd160-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160,umac-128@openssh.com
====
CLIENT SIDE:
/etc/ssh/ssh_config
Host *
KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-ripemd160-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160,umac-128@openssh.com
====
ssh-keygen -t ed25519 -a 256 -f yourkey.key -C whateveryouwant
Re: Upgrade your SSH keys
#44If you have servers too old to work with the latest keys, you can easily modify your ~/.ssh/config to automatically use a per-machine private key file:
Host foo.example.com
Keyfile ~/.ssh/my_obsolete_private_keyfileRe: Upgrade your SSH keys
#45Noob 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?
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.
Re: Upgrade your SSH keys
#46Noob 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?
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.
Re: Upgrade your SSH keys
#47Noob 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?
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.
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.
Re: Upgrade your SSH keys
#48In Userify (ssh key manager that only distributes sudo roles and public keys -- you keep your private keys[1]) we're going to be disallowing DSS keys soon. I like this post - it's good advice overall. Keys are easy to handle and in some ways more secure than certificate management (which relies on extra unnecessary infrastructure). 1. https://userify.com
Off topic, but I want to thank you guys again for your service. You guys make it so freaking easy to manage access to our various servers and VMs- I can't even remember how we used to deal with it.
Thank you! I don't know who you are (feel free to email me @ userify.com) but we really really really love to hear stuff like that. We are launching in AWS Mktplace soon too btw!
Re: Upgrade your SSH keys
#49Earlier 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.
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.)
Re: Upgrade your SSH keys
#50What's the problem with ECDSA?