On 2014-05-13 at 09:57 -1000, Mathew Snyder wrote: > SSH.com states that SSH is _not_ affected by the bug. I haven't found > anything regarding openSSH, though.
As others have noted: the protocol doesn't use TLS, so no. > We are currently in a discussion as to whether or not we should be updating > the host keys across our entire enterprise. If SSH doesn't use TLS, which > the bug affects, is it necessary to replace the host keys? If you're after a host key replacement project, then consider this: The SSH protocol mandates that DSA keys used for identity (host or client) use SHA-1. The DSA specs mandate that keys larger than 1024 bits use a hash from the SHA-2 family. So a few years ago, the OpenSSH developers solved the interop problem by capping the size of DSA keys to 1024 bits. Pick your favourite set of key length recommendations from keylength.com; I tend to use <http://www.keylength.com/en/3/> -- thus DSA keys of 1024 bits are smaller than the "smallest general purpose level". With SSH, you really want to have more than one algorithm available, so that if there's a significant crypto advance then you can readily disable one family and still have everyone able to connect; but this approach requires _equivalent_ strength crypto, and DSA is being handicapped to be much _much_ weaker. So if you have the time and inclination for a site-wide deployment project, then grab the very latest OpenSSH (6.6.1p1; there's a fix against 6.6p1 which vendors have been asked to bundle), get that deployed everywhere, then migrate to having all hosts have DSA disabled as a host key and using either "RSA + ECDSA + Ed25519" or "RSA + Ed25519", depending upon whether or not you still trust ECDSA after last year's revelations. (I do, but I'm not a cryptanalyst). Your next challenge is then restricting which keys _users_ can use, if you let users directly edit a file which holds all their authorized_keys and which goes unmodified to all servers, since AFAIK there's no way in OpenSSH to selectively disable client key algorithms, short of recompiling with the support patched out. Which you might do. This is more involved than "redeploy all host keys with the same algorithms" but is good hygiene to look at and make sure your processes can handle. -- My employer, Apcera Inc, is hiring sysadmin; primarily San Francisco: http://www.apcera.com/jobs/#operations-engineer (but all the mistakes in this email are made in my personal capacity)
pgpXCS_D_m1TG.pgp
Description: PGP signature
_______________________________________________ Tech mailing list [email protected] https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
