The defaults for HostKeyAlgorithms option are: ecdsa-sha2-nistp256-cert-v01 at openssh.com, ecdsa-sha2-nistp384-cert-v01 at openssh.com, ecdsa-sha2-nistp521-cert-v01 at openssh.com, ssh-ed25519-cert-v01 at openssh.com, ssh-rsa-cert-v01 at openssh.com, ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521, ssh-ed25519,ssh-rsa Why does OpenSSH prefer older and less secure (https://safecurves.cr.yp.to/) ECDSA with NIST curves over Ed25519? Also why are smaller key, curve and hash sizes preferred over bigger ones? The default ciphers are: chacha20-poly1305 at openssh.com, aes128-ctr,aes192-ctr,aes256-ctr, aes128-gcm at openssh.com,aes256-gcm at openssh.com Why is CTR mode preferred over GCM? Usually, AEAD ciphers are preferred over non-AEAD ones. The default MACs are: umac-64-etm at openssh.com,umac-128-etm at openssh.com, hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com, hmac-sha1-etm at openssh.com, umac-64 at openssh.com,umac-128 at openssh.com, hmac-sha2-256,hmac-sha2-512,hmac-sha1 Why is UMAC preferred over HMAC? UMAC is less widely known and does not have as much research done on its security as HMAC. Also, in ssh-rsa-cert-v01 at openssh.com case the certificate is signed using SHA-1, allowing the certificate signature to be forged. In ssh-rsa case the attack is mitigated because the data is hashed with SHA-256 before being signed. I suggest disabling this method by default.
Answering the first part of your mail: On 2018-05-25, Yegor Ievlev <koops1997 at gmail.com> wrote:> The defaults for HostKeyAlgorithms option are: > > ecdsa-sha2-nistp256-cert-v01 at openssh.com, > ecdsa-sha2-nistp384-cert-v01 at openssh.com, > ecdsa-sha2-nistp521-cert-v01 at openssh.com, > ssh-ed25519-cert-v01 at openssh.com, > ssh-rsa-cert-v01 at openssh.com, > ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521, > ssh-ed25519,ssh-rsa > > Why does OpenSSH prefer older and less secure > (https://safecurves.cr.yp.to/) ECDSA with NIST curves over Ed25519?Changing HostKeyAlgorithms means that the existing entries in known_hosts don't match, so the "WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED" message is triggered.
https://man.openbsd.org/ssh_config If hostkeys are known for the destination host then this default is modified to prefer their algorithms. On Sat, May 26, 2018 at 5:54 PM, Stuart Henderson <stu at spacehopper.org> wrote:> Answering the first part of your mail: > > On 2018-05-25, Yegor Ievlev <koops1997 at gmail.com> wrote: >> The defaults for HostKeyAlgorithms option are: >> >> ecdsa-sha2-nistp256-cert-v01 at openssh.com, >> ecdsa-sha2-nistp384-cert-v01 at openssh.com, >> ecdsa-sha2-nistp521-cert-v01 at openssh.com, >> ssh-ed25519-cert-v01 at openssh.com, >> ssh-rsa-cert-v01 at openssh.com, >> ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521, >> ssh-ed25519,ssh-rsa >> >> Why does OpenSSH prefer older and less secure >> (https://safecurves.cr.yp.to/) ECDSA with NIST curves over Ed25519? > > Changing HostKeyAlgorithms means that the existing entries in known_hosts > don't match, so the "WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED" > message is triggered. > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
On 2018-05-26, Stuart Henderson <stu at spacehopper.org> wrote:> Changing HostKeyAlgorithms means that the existing entries in known_hosts > don't match, so the "WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED" > message is triggered.That's not true. I'm using the default HostKeyAlgorithms along with a known_hosts file composed almost entirely of ssh-ed25519 entries. The first entry in HostKeyAlgorithms is only used to pick the key type on first contact; afterwards ssh uses the key type from known_hosts as long as that type has an entry somewhere in HostKeyAlgorithms. As ssh_config(5) says under HostKeyAlgorithms: If hostkeys are known for the destination host then this default is modified to prefer their algorithms. -- Christian "naddy" Weisgerber naddy at mips.inka.de
On 2018-05-25, Yegor Ievlev <koops1997 at gmail.com> wrote:> The defaults for HostKeyAlgorithms option are: [...] > Why does OpenSSH prefer older and less secure > (https://safecurves.cr.yp.to/) ECDSA with NIST curves over Ed25519?I asked Markus and Damien about this in the past but honestly don't remember the answer. Some of the potential reasons (lack of standardization, no DNS fingerprint, ...) seem to no longer apply. I've been wanting to hassle Markus and Damien about this again, once I run into them in person, but that opportunity hasn't presented itself yet.> Also why are smaller key, curve and hash sizes preferred over bigger > ones?Reasonable trade-off between security and performance.> The default ciphers are: [...] > Why is CTR mode preferred over GCM?GCM performs poorly without hardware support for carry-less multiplication.> The default MACs are: [...] > Why is UMAC preferred over HMAC? UMAC is less widely known and does > not have as much research done on its security as HMAC.UMAC has a security proof and performs very well. -- Christian "naddy" Weisgerber naddy at mips.inka.de
On Sat, 26 May 2018, Christian Weisgerber wrote:> On 2018-05-25, Yegor Ievlev <koops1997 at gmail.com> wrote: > > > The defaults for HostKeyAlgorithms option are: [...] > > Why does OpenSSH prefer older and less secure > > (https://safecurves.cr.yp.to/) ECDSA with NIST curves over Ed25519? > > I asked Markus and Damien about this in the past but honestly don't > remember the answer. Some of the potential reasons (lack of > standardization, no DNS fingerprint, ...) seem to no longer apply. > I've been wanting to hassle Markus and Damien about this again, > once I run into them in person, but that opportunity hasn't presented > itself yet.Yeah, there's no RFC for ed25519 keys yet. There's an I-D in progress at https://tools.ietf.org/id/draft-ietf-curdle-ssh-ed25519-01.html Christian is right about our reasoning for the other choices. -d