that is the state of OpenSSL in Fedora after this morining https://bugzilla.redhat.com/show_bug.cgi?id=319901#c108
since OpenSSL in Fedora from now on supports ECDHE depending software needs to be rebuilt to make use of it as well as libraries like NSS/GNUTLS should do the same and depending packages like Firefox needs a rebuild against refreshed NSS to support it also on the client side i made some triage today _____________________________________________________ openssl: https://bugzilla.redhat.com/show_bug.cgi?id=319901#c108 nss-softokn https://bugzilla.redhat.com/show_bug.cgi?id=1019244 nss https://bugzilla.redhat.com/show_bug.cgi?id=1019245 firefox https://bugzilla.redhat.com/show_bug.cgi?id=1019247 thunderbird: https://bugzilla.redhat.com/show_bug.cgi?id=1019249 httpd: https://bugzilla.redhat.com/show_bug.cgi?id=1019251 dovecot: https://bugzilla.redhat.com/show_bug.cgi?id=1019253 postfix: https://bugzilla.redhat.com/show_bug.cgi?id=1019254 openssh: https://bugzilla.redhat.com/show_bug.cgi?id=1019256 dbmail: https://bugzilla.redhat.com/show_bug.cgi?id=1019259
after switch from openssl-1.0.1e-4.fc18.1 running for some days without any single issue today to openssl-1.0.1e-28.fc18 with a rebuilt postfix 2.10.2 a few of the messages below Oct 21 20:26:44 mail postfix/smtp[2217]: warning: TLS library problem: 2217:error:100AE081:elliptic curve routines:EC_GROUP_new_by_curve_name:unknown group:ec_curve.c:316 may this be related to the follwoing change and if so how to avoid this? fianlly with opportunistic TLS in postfix it leads to deliver the message unencrypted * Wed Oct 16 2013 Tomáš Mráz <tmraz> 1.0.1e-28 - only ECC NIST Suite B curves support
I'd need a reproducer for this to investigate. We cannot enable other curves than ECC NIST Suite B unfortunately.
http://koji.fedoraproject.org/koji/buildinfo?buildID=477199 - rebuild with the openssl with the ECC support - increase the size of the Diffie-Hellman groups (#1010607) - sshd-keygen to generate ECDSA keys <i.grok> (#1019222) so the main question here is why not for F18/F19
openssh-6.2p2-6.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/openssh-6.2p2-6.fc19
there is a fresh openssh build for F18 on koji http://koji.fedoraproject.org/koji/buildinfo?buildID=479133 but F18 openssl was not rebuilt with "add back support for secp521r1 EC curve" http://koji.fedoraproject.org/koji/buildinfo?buildID=477538 so i am not sure if this should not be done first on my F19 machines today i generated ECDSA keys which are working fine ecdsa-sha2-nistp521
There is no need to rebuild against the openssl build that just adds an additional EC curve.
thanks for feedback - better be safe than sorry after the postfix-troubles caused by the second openssh-rebuild witch fewer curves in comments 2 since i plan to rollout openssh with ECDSA support which needs coordination over the infrastructure by changes in "known_hosts" otherwise breaking key authenticated cron scripts
well, and taht fails on F18 while it works on F19 ssh-keygen -t ecdsa -b 521 -f /etc/ssh/ssh_host_ecdsa_key Generating public/private ecdsa key pair. ecdsa_generate_private_key: EC_KEY_new_by_curve_name failed
openssh-6.2p2-6.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
(In reply to Harald Reindl from comment #9) > well, and taht fails on F18 while it works on F19 > > ssh-keygen -t ecdsa -b 521 -f /etc/ssh/ssh_host_ecdsa_key > Generating public/private ecdsa key pair. > ecdsa_generate_private_key: EC_KEY_new_by_curve_name failed That's because I did not add the secp521r1 EC curve to OpenSSL in F18 yet.
a F18 build with secp521r1 would be greatly appreciated because i would like to avoid "error: Could not load host key: /etc/ssh/ssh_host_ecdsa_key" as well as generate lower ecdsa-hostkeys for around 20 machines in the hope having them for many years without need to regenerate (the amchines are initially installed with Fedora 9 and made all dist-upgrades with yum to F18)
ssh-add has problems with ecdsa keys: # ssh-add id_ecdsa Enter passphrase for id_ecdsa: Error reading response length from authentication socket. Could not add identity: id_ecdsa (seen on openssh-6.2p2-6.fc19.x86_64, ditto for fc20.x86_64)
> ssh-add has problems with ecdsa keys not really "ssh-add" is in my KDE autostart, there is a RSA key as well as a secp521r1 ecdsa, both with the same password, the window-title asks for the password for id_rsa but for sure unlocks also id_ecdsa proven by comment out the RSA key in "authorized_keys" and connection to a F19 openssh works fine, if i comment out the ecdsa key on the server too it fails, so it's proven that it is unlocked and used _____________________________ the missing secp521r1 on F18 on the other hand is a *serious problem* if the client decides to use ECDSA and has a secp521r1 key Nov 22 12:01:21 buildserver sshd[27899]: fatal: key_from_blob: EC_KEY_new_by_curve_name failed [preauth] Nov 22 12:01:21 buildserver sshd[27919]: fatal: key_from_blob: EC_KEY_new_by_curve_name failed [preauth] Nov 22 12:01:23 buildserver sshd[27939]: fatal: key_from_blob: EC_KEY_new_by_curve_name failed [preauth] Nov 22 12:01:24 buildserver sshd[27959]: fatal: key_from_blob: EC_KEY_new_by_curve_name failed [preauth] Nov 22 12:01:24 buildserver sshd[27979]: fatal: key_from_blob: EC_KEY_new_by_curve_name failed [preauth] Nov 22 12:01:24 buildserver sshd[27999]: fatal: key_from_blob: EC_KEY_new_by_curve_name failed [preauth] Nov 22 12:01:29 buildserver sshd[28019]: fatal: key_from_blob: EC_KEY_new_by_curve_name failed [preauth] Nov 22 12:01:29 buildserver sshd[28039]: fatal: key_from_blob: EC_KEY_new_by_curve_name failed [preauth] Nov 22 12:01:29 buildserver sshd[28059]: fatal: key_from_blob: EC_KEY_new_by_curve_name failed [preauth] Nov 22 12:01:29 buildserver sshd[28079]: fatal: key_from_blob: EC_KEY_new_by_curve_name failed [preauth] Nov 22 12:01:31 buildserver sshd[28099]: fatal: key_from_blob: EC_KEY_new_by_curve_name failed [preauth] Nov 22 12:01:32 buildserver sshd[28119]: fatal: key_from_blob: EC_KEY_new_by_curve_name failed [preauth] Nov 22 12:01:32 buildserver sshd[28139]: fatal: key_from_blob: EC_KEY_new_by_curve_name failed [preauth] Nov 22 12:01:32 buildserver sshd[28159]: fatal: key_from_blob: EC_KEY_new_by_curve_name failed [preauth] Nov 22 12:01:32 buildserver sshd[28179]: fatal: key_from_blob: EC_KEY_new_by_curve_name failed [preauth] Nov 22 12:02:33 buildserver sshd[28206]: fatal: key_from_blob: EC_KEY_new_by_curve_name failed [preauth]
Ignoring for an instant the fact that ssh-add -D is also buggy and doesn't delete the RSA/DSA keys loaded at login, one still has the failing ecdsa load and subsequent ssh login failure. [wolfgang@arbol .ssh]$ ssh-add -D All identities removed. [wolfgang@arbol .ssh]$ ssh-add -l 1024 e9:f5:de:45:c5:d3:3a:51:3a:16:d9:4f:e8:98:3c:be wolfgang+20130608.com (DSA) 4096 c6:5b:e8:bb:de:a8:48:69:ca:02:40:bc:ea:63:0f:ce wolfgang+20130908.com (RSA) [wolfgang@arbol .ssh]$ ssh-add id_ecdsa Enter passphrase for id_ecdsa: Error reading response length from authentication socket. Could not add identity: id_ecdsa [wolfgang@arbol .ssh]$ ssh-add -l 1024 e9:f5:de:45:c5:d3:3a:51:3a:16:d9:4f:e8:98:3c:be wolfgang+20130608.com (DSA) 4096 c6:5b:e8:bb:de:a8:48:69:ca:02:40:bc:ea:63:0f:ce wolfgang+20130908.com (RSA) [wolfgang@arbol .ssh]$ mv authorized_keys authorized_keys.save [wolfgang@arbol .ssh]$ cat id_ecdsa > authorized_keys [wolfgang@arbol .ssh]$ cat authorized_keys -----BEGIN EC PRIVATE KEY----- Proc-Type: 4,ENCRYPTED DEK-Info: AES-128-CBC,1CB148A28F58A321E5DB85BEFBB960D9 VofBfEi0Q6PFXP4yRjemW/oN3Lglzmr9zq00+QwdQhL31cFTe3KTnK4D5MBs4rnA v4BL3gWaeQA4Ni2rwPo05O/eAton48CKdrgiqtjGqflYgiv6189hb11CR/QmzIDE 8DoTLjAGvIigu2P5fgKkY/B60YU/W8BySV2kgd54/zw= -----END EC PRIVATE KEY----- [wolfgang@arbol .ssh]$ ssh-add id_ecdsa Enter passphrase for id_ecdsa: Error reading response length from authentication socket. Could not add identity: id_ecdsa [wolfgang@arbol .ssh]$ ssh arbol Permission denied (publickey). [wolfgang@arbol .ssh]$ Invoking ssh with -vvvv also shows that no ecdsa key is ever offered. BTW. This is under cinnamon both under fc19 and fc20. Perhaps cinnamon uses its own ssh-agent which somehow interferes (hence the ssh-add -D failure?)
as said i call "ssh-add" without *any* param in my KDE autostart and it works, even if it is a CLI command there is a graphical window asking for the password of my ssh-key as first thing which appears due login
This is not a problem of ssh-agent, but the ssh-agent functionality in gnome-keyring (or how the keyring daemon is called in cinnamon).
(In reply to Tomas Mraz from comment #17) > This is not a problem of ssh-agent, but the ssh-agent functionality in > gnome-keyring (or how the keyring daemon is called in cinnamon). Spot on. https://bugzilla.gnome.org/show_bug.cgi?id=641082 (no ecdsa support in gnome-keyring) Work around in cinnamon, uncheck gnome-keyring/ssh-agent in startup preferences. ecdsa then works.
> That's because I did not add the secp521r1 EC curve to OpenSSL in F18 yet is there a good reason to still break interopability between F19/F18 machines? IdentityFile ~/.ssh/id_ecdsa IdentityFile ~/.ssh/id_rsa breaks connections to F18 machines and switch the order results in not use ECDSA at all while the refresehd OpenSSL would solve this
There's a fix for this at upstream's code: + - (dtucker) [configure.ac kex.c key.c myproposal.h] Test for the presence of + NID_X9_62_prime256v1, NID_secp384r1 and NID_secp521r1 and test that the + latter actually works before using it. Fedora (at least) has NID_secp521r1 + that doesn't work (see https://bugzilla.redhat.com/show_bug.cgi?id=1021897). I'll apply this and update soon.
this patch is good and solves one problem *but* i would like to generate ECDSA keys and i would like to do so with secp521r1 now and not in 2014 where upgrade to F19 is planned here because distribute "known_hosts" is funny but only once every 5 years
see https://admin.fedoraproject.org/updates/FEDORA-2013-23074/openssl-1.0.1e-31.fc19
see http://koji.fedoraproject.org/koji/buildinfo?buildID=483665 since we are still talking about F18 as i also said "and not in 2014 where upgrade to F19 is planned here" oepnssl-1.0.1e-31 for F18 was buiult Mon, 09 Dec 2013 16:01:10 UTC i already gave karma yesterday night and rolled it out inlcuding ECDSA-HOST/Private-Keys
openssh-6.4p1-3.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/openssh-6.4p1-3.fc20
Package openssh-6.4p1-3.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing openssh-6.4p1-3.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-23163/openssh-6.4p1-3.fc20 then log in and leave karma (feedback).
openssh-6.4p1-3.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.