Bug 1019256 - ECDHE: now supported in Fedora's OpenSSL
ECDHE: now supported in Fedora's OpenSSL
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: openssh (Show other bugs)
18
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Petr Lautrbach
Fedora Extras Quality Assurance
:
Depends On:
Blocks: ecc
  Show dependency treegraph
 
Reported: 2013-10-15 07:24 EDT by Harald Reindl
Modified: 2013-12-16 02:05 EST (History)
8 users (show)

See Also:
Fixed In Version: openssh-6.4p1-3.fc20
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-12-16 02:05:28 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Harald Reindl 2013-10-15 07:24:41 EDT
that is the state of OpenSSL in Fedora after this morining
https://bugzilla.redhat.com/show_bug.cgi?id=319901#c108
Comment 1 Harald Reindl 2013-10-15 07:31:28 EDT
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
Comment 2 Harald Reindl 2013-10-21 16:33:59 EDT
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@redhat.com> 1.0.1e-28 
- only ECC NIST Suite B curves support
Comment 3 Tomas Mraz 2013-10-22 03:05:17 EDT
I'd need a reproducer for this to investigate. We cannot enable other curves than ECC NIST Suite B unfortunately.
Comment 4 Harald Reindl 2013-11-11 08:15:51 EST
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@comcast.net> (#1019222)

so the main question here is why not for F18/F19
Comment 5 Fedora Update System 2013-11-18 08:30:57 EST
openssh-6.2p2-6.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/openssh-6.2p2-6.fc19
Comment 6 Harald Reindl 2013-11-18 16:13:39 EST
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
Comment 7 Tomas Mraz 2013-11-18 16:24:56 EST
There is no need to rebuild against the openssl build that just adds an additional EC curve.
Comment 8 Harald Reindl 2013-11-18 16:29:11 EST
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
Comment 9 Harald Reindl 2013-11-18 17:43:07 EST
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
Comment 10 Fedora Update System 2013-11-19 00:27:37 EST
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.
Comment 11 Tomas Mraz 2013-11-19 03:40:15 EST
(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.
Comment 12 Harald Reindl 2013-11-19 20:19:39 EST
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)
Comment 13 Wolfgang Rupprecht 2013-11-22 07:02:06 EST
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)
Comment 14 Harald Reindl 2013-11-22 07:08:43 EST
> 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]
Comment 15 Wolfgang Rupprecht 2013-11-22 07:29:22 EST
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@arbol.wsrcc.com (DSA)
4096 c6:5b:e8:bb:de:a8:48:69:ca:02:40:bc:ea:63:0f:ce wolfgang+20130908@arbol.wsrcc.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@arbol.wsrcc.com (DSA)
4096 c6:5b:e8:bb:de:a8:48:69:ca:02:40:bc:ea:63:0f:ce wolfgang+20130908@arbol.wsrcc.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?)
Comment 16 Harald Reindl 2013-11-22 07:38:36 EST
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
Comment 17 Tomas Mraz 2013-11-22 07:44:38 EST
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).
Comment 18 Wolfgang Rupprecht 2013-11-22 08:12:28 EST
(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.
Comment 19 Harald Reindl 2013-12-03 19:13:54 EST
> 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
Comment 20 Petr Lautrbach 2013-12-04 09:47:08 EST
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.
Comment 21 Harald Reindl 2013-12-04 10:38:54 EST
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
Comment 23 Harald Reindl 2013-12-11 09:28:37 EST
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
Comment 24 Fedora Update System 2013-12-11 09:55:40 EST
openssh-6.4p1-3.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/openssh-6.4p1-3.fc20
Comment 25 Fedora Update System 2013-12-11 11:44:28 EST
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).
Comment 26 Fedora Update System 2013-12-16 02:05:28 EST
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.

Note You need to log in before you can comment on or make changes to this bug.