Talk:Security/Guidelines/OpenSSH

Question from JanZerebecki

Shouldn't HostKeyAlgorithms 1) have ecdsa-sha2-nistp256-cert-v01@openssh.com after ecdsa-sha2-nistp384-cert-v01@openssh.com and 2) not list all openssh.com variants first but primarily order by algorithm?

New suggestion:

HostKeyAlgorithms ssh-ed25519-cert-v01@openssh.com,ssh-ed25519,ssh-rsa-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-rsa,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp521,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp384,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp256

-JanZerebecki (talk) 10:28, 2 March 2015 (PST)

Reply from kang

1) Fixed, thanks!

2) There's an argument to be add for cert keys vs no cert keys. I linked the doc and we currently prefer cert keys, even thus the negociated algorithm may be weaker (eg ecdsa sha2 nistp256 with cert keys prefered to ecdsa sha nistp521 without cert).

Security trade off for aes128-gcm ?

After reading https://stribika.github.io/2015/01/04/secure-secure-shell.html#changelog and http://blog.djm.net.au/2013/11/chacha20-and-poly1305-in-openssh.html I get the impression that aesX-gcm and aesX-ctr in EtM mode all have the downside of sending the packet size in plain text. Is there any other reason for avoiding aesX-gcm? If not then they should be added or aesX-ctr should be removed. (Only leaving chacha20-poly1305 is probably not a good idea because of the need for backwards compatibility.) -JanZerebecki (talk) 07:58, 16 April 2015 (PDT)

Reply from kang

Indeed, this is a mistake. I added it as default for modern. Potentially, we could split into Modern with CHACHA20 only, Intermediate with CHACHA20+AES* and Old (which would be the current intermediate). I suspect we'll do that after the next round of "commonly used distro upgrade" so that most have CHACHA20 support and able to follow moderm. Hopefully, third party clients such as Putty, JuiceSSH, etc. will also follow.

Ciphers directive given twice in modern client config

The "modern" client configuration specifies two sets of ciphers. This seems to be a bug; OpenSSH will ignore the second set of ciphers given. Liujed (talk) 00:15, 22 May 2015 (PDT)

Yes the first line should have been deleted when the second was added. I went ahead and fixed that. -JanZerebecki (talk) 03:55, 27 May 2015 (PDT)