Comments on: Reasonable SSH Security For OpenSSH 6.0 Or Later https://pthree.org/2015/01/12/reasonable-ssh-security-for-openssh-6-0-or-later/ Linux. GNU. Freedom. Wed, 13 Dec 2017 19:29:15 +0000 hourly 1 https://wordpress.org/?v=5.0-alpha-42199 By: Christopher Smith https://pthree.org/2015/01/12/reasonable-ssh-security-for-openssh-6-0-or-later/#comment-257388 Thu, 24 Dec 2015 07:01:15 +0000 https://pthree.org/?p=4006#comment-257388 While chacha20-poly1305 might not be quite as thoroughly tested, it does seem to a have a reasonably well established security profile now, --enough that CloudFlare is preferring it with their TLS. The ssh implementation of the protocol provides added protection against traffic analysis that isn't there in the other protocols. I'd argue it is a reasonable default choice for a lot of situations, particularly for processors that lack native AES instructions.

]]>
By: nsa https://pthree.org/2015/01/12/reasonable-ssh-security-for-openssh-6-0-or-later/#comment-252654 Fri, 16 Oct 2015 12:44:18 +0000 https://pthree.org/?p=4006#comment-252654 How about a revision after the knowledge from
http://arstechnica.com/security/2015/10/how-the-nsa-can-break-trillions-of-encrypted-web-and-vpn-connections/

DH

]]>
By: Mat https://pthree.org/2015/01/12/reasonable-ssh-security-for-openssh-6-0-or-later/#comment-229309 Mon, 16 Mar 2015 19:12:14 +0000 https://pthree.org/?p=4006#comment-229309 The AES GCM ciphers should be the preferred ciphers on all modern CPUs (2.47 cycles per byte). It also includes the authentication and a separate hmac is not necessary.

]]>
By: Aaron Toponce https://pthree.org/2015/01/12/reasonable-ssh-security-for-openssh-6-0-or-later/#comment-227910 Tue, 17 Feb 2015 21:26:35 +0000 https://pthree.org/?p=4006#comment-227910 Using AES without hardware accelerated AES seems to pin the CPU before the disks or network become the bottleneck. I transferred an ISO with rsync(1) from my workstation which has a 4-year old Intel i7 to a server with an Intel Xeon. Neither have onboard AES hardware instructions, and I can only sustain about 82 MBps between connections on a local gigabit link after 4-5 tests. Certainly acceptable for "most applications". While watching the CPU, one of the cores on my i7 is 100% pegged (about 80% pegged on the Xeon). Now, changing that to arcfour, I see an increased throughput of 97 MBps with 50% CPU utilization on my workstation (about 40% on the Xeon). Either the disk or the LAN is the bottleneck here. Changing to "chacha20-poly1305@openssh.com" also shows similar performance to "arcfour". Again, after 4-5 tests.

I agree about the security of "chacha20poly1305@openssh.com" not being near as analyzed as AES. And I'll make no assumptions about its security, nor for ECC. If you're not comfortable using them, don't use them. Stick with tried and true, indeed.

]]>
By: ThatPeskyCryptoGuy https://pthree.org/2015/01/12/reasonable-ssh-security-for-openssh-6-0-or-later/#comment-224932 Fri, 16 Jan 2015 08:55:39 +0000 https://pthree.org/?p=4006#comment-224932 "AES will pin the CPU before flooding the pipe"
Not on any "modern" (few years old) desktop grade hardware (it's true for Raspberry Pi). Slow transfers are caused by SSH networking magic and not CPU taxation caused by encryption. Yes there are differences in speed for different algorithms but still it's not the problem. Read about HPN-SSH. It's not included fully in the mainstream implementation of OpenSSH (matter of priorities for SSH devs). This is why SSH (SCP or SFTP actually) can transfer files in the ballpark of good 10MB/s and that's it. One of three things that suck for me about OpenSSH. Two others are lack of information about established tunnels - simple and needed thing but not implemented and compression that really sucks both in speed and in effectiveness - it's not sensible to turn it on unless you are on a REALLY slow link (128kb/s or less) because it adds a ton of latency and again CPU is not the bottleneck here.

Using chacha20-poly1305 as default is risky - it's not analyzed nearly as well as AES. I would say it's not analyzed well at all... The same thing is true for the new SSH ECC algorithms (for lesser extent but still).

]]>
By: Aaron Toponce https://pthree.org/2015/01/12/reasonable-ssh-security-for-openssh-6-0-or-later/#comment-224422 Mon, 12 Jan 2015 16:47:10 +0000 https://pthree.org/?p=4006#comment-224422 After I posted it, I realized that I probably could have extended it all the way back to OpenSSH 4.0, with minimal difficulty. Oh well. Maybe a follow-up post. 🙂

]]>
By: Frew Schmidt https://pthree.org/2015/01/12/reasonable-ssh-security-for-openssh-6-0-or-later/#comment-224414 Mon, 12 Jan 2015 15:32:32 +0000 https://pthree.org/?p=4006#comment-224414 Thanks for posting this! I was pretty annoyed when I started implementing the originally recommended changes and then realized that they won't work for any of my servers (debian.)

It might be cool if, in an appendix, you should a good way to install the backported latest versions of OpenSSH on Debian servers, since that would probably be the best path forward if doable.

]]>