Bug 1019256

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.