The current default /etc/sshd_config and /etc/ssh_config files have insecure defaults. The worst of which is a severe limitation of the used server key to 1024 bits. See URL for safe recommendations. NB: The document assumes OpenSSH 6.1 which has not been stabilized yet. So adapt to older versions. Reproducible: Always
Can you give examples of what you've like changed and what you have an issue with? As far as key size, from what I can tell our default DSA size is 1024 while RSA is 2048 and ECDSA is 256.
also note that the keys are presented in preferential order -- ecdsa, then rsa, then dsa.
NB: I am not a crypto expert. But looking at the referenced document, they suggest to use RSA only, because DSA key size of 1024 is insufficient. Even if DSA is tried last, I suggest to disable DSA explicitly in the default config: Protocol 2 HostKey /etc/ssh/ssh_host_rsa_key # 1024 bit DSA keys are not secure #HostKey /etc/ssh/ssh_host_dsa_key HostKey /etc/ssh/ssh_host_ecdsa_key As far as I understand, any ECDSA key should be fine (as minimum key size is 256 bits, which is roughly equivalent to 128 bit symmetric keys). The paper also restricts the available Ciphers, MACs and key exchange algorithms, which makes a lot of sense in my opinion: The default Ciphers include RC4, the default MACs includes MD5 (as first option!), and the default KexAlgorithms list the (at least controversial) NIST curvers as first options. So the defaults allow downgrade attacks or directly result in easily broken encryption. Thanks for yesterday's openssh bump by the way :-) However, for curve25519-sha256@libssh.org to work, we need >=net-libs/libssh-0.6.0_rc1 stabilized!
(In reply to Ortwin Glueck from comment #3) i don't think so. DSA is tried last only when other key types are not available. which means, the only things trying to use DSA are things that don't support ECDSA/RSA/etc... which means they don't get to even log in when DSA is off. same goes for the ciphers. the server says "i support these and this is the preference" but really it's up to the client to select the best possible. if the client restricts itself to just RC4, then why is the client being dumb ? if these defaults are good enough for the upstream openssh maintainers, i don't see a compelling reason to remove them in Gentoo today. hand maintaining these lists is a pita because it means we have to re-evaluate the list every time we bump the package or add a patch (like hpn).
(In reply to SpanKY from comment #4) > which means they don't get to even log in when DSA is off. Exactly, that's the intended behaviour. If someone needs DSA they are free to enable it. But then they should know that they create a vulnerability. > same goes for the ciphers. the server says "i support these and this is the > preference" but really it's up to the client to select the best possible. > if the client restricts itself to just RC4, then why is the client being > dumb ? Because the security of the server should not depend on the client's choices! With the same argument you could install telnetd alongside with sshd and offer users to chose which to use... It's OBVIOUSLY dump to do that, right? > if these defaults are good enough for the upstream openssh maintainers, i > don't see a compelling reason to remove them in Gentoo today. Well, the authors of that paper DO have a compelling reason to change defaults. > hand > maintaining these lists is a pita Security is ALWAYS a pita.
