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-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-
gcm@openssh.com,aes256-ctr,aes128-ctr

MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-
etm@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160

KexAlgorithms curve25519-sha256@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