On Wednesday 25 Jun 2014 22:10:42 Stefan G. Weichinger wrote: > Am 25.06.2014 21:49, schrieb Alan McKinnon: > > I've also noticed slowdowns recently, I think it's the new ciphers likes > > ecdsa. Try this: > > > > Connect using ssh -vvv and examine the output to find which of the > > various ciphers and algorithms are used once connection is achieved. On > > the client, add those configuration options for the server to > > ssh_config. You should notice a speed up on the next attempt as unused > > methods will be skipped > > > > man 5 ssh_config > > > > has all the details > > ;-) > > thanks, Alan. > > Did you already find out what options to set? > > Aside from that, I wonder why we as users have to do that and why it > isn't set up "as good as possible" by the coders of openssh.
Because the "as good as possible" datum is being redefined post Snowden. > I will see if I can figure out what to do ... The Better Crypto team suggest: Ciphers chacha20-poly1...@openssh.com,aes256-...@openssh.com,aes128- g...@openssh.com,aes256-ctr,aes128-ctr MACs hmac-sha2-512-...@openssh.com,hmac-sha2-256-...@openssh.com,umac-128- e...@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160 KexAlgorithms curve25519-sha...@libssh.org,diffie-hellman-group-exchange- sha256,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1 The above may be OTT for ssh connections between machines within a trusted LAN. As has already been mentioned if you choose your favourite crypto and strip out all the rest, then the negotiation ought to be faster between modern PCs. -- Regards, Mick
signature.asc
Description: This is a digitally signed message part.
