Upon trying to start the sshd service on the newest amd64 installcd, it throws this error: * Generating ecdsa host key ... Generating public/private key pair. ssh-keygen: symbol lookup error: ssh-keygen: undefined symbol: EC_KEY_new_curve_by_name * ERROR: sshd failed to start It seems that the installcd's net-misc/openssh was built against dev-libs/openssl[-bindist], so ecdsa support was left enabled in the sshd init script. But the final installcd ships with dev-libs/openssl[bindist] which strips out ecdsa support, causing the sshd init script to fail.
@base-system: Perhaps the best way to fix this is to add a bindist use flag to openssh and make sure we have a dev-libs/openssl[bindist?] dependency.
Given that there isn't a decent way to turn off ECC in OpenSSH when building against an ECC capable OpenSSL, I'd vote for [bindist=] instead.
In case someone's stuck and MUST install via one of these livecd's & sshd, these commands can work around the issue: # sed -i -e "s/ && gen_key ecdsa//" /etc/init.d/sshd # sed -i -e "/_rsa/s/^#//" -e "/_dsa/s/^#//" /etc/ssh/sshd_config # /etc/init.d/ssh restart Works here, anyway.
(In reply to comment #3) > In case someone's stuck and MUST install via one of these livecd's & sshd, > these commands can work around the issue: > > # sed -i -e "s/ && gen_key ecdsa//" /etc/init.d/sshd > # sed -i -e "/_rsa/s/^#//" -e "/_dsa/s/^#//" /etc/ssh/sshd_config > # /etc/init.d/ssh restart > > > Works here, anyway. SSHD starts but without possibility to handle incoming connections.
This is still a problem with the current amd64 minimal install iso.
(In reply to comment #2) > Given that there isn't a decent way to turn off ECC in OpenSSH when building > against an ECC capable OpenSSL, I'd vote for [bindist=] instead. I am going to implement this change in time for the 20111105 snapshot unless I get a huge complaint. This has been open with a known simple solution for far too long.
(In reply to comment #6) > (In reply to comment #2) > > Given that there isn't a decent way to turn off ECC in OpenSSH when building > > against an ECC capable OpenSSL, I'd vote for [bindist=] instead. > > I am going to implement this change in time for the 20111105 snapshot unless > I get a huge complaint. This has been open with a known simple solution for > far too long. Sorry, I obviously mean 20121105
as promised, I changed all of the openssh ebuilds in the manner suggested by Diego: -IUSE="${HPN_PATCH:++}hpn kerberos ldap libedit pam selinux skey static tcpd X X509" +IUSE="bindist ${HPN_PATCH:++}hpn kerberos ldap libedit pam selinux skey static tcpd X X509" - >=dev-libs/openssl-0.9.6d + >=dev-libs/openssl-0.9.6d[bindist=] I tested this method and found it to be reasonably solid for this bug fix, and safe enough to not harm the tree, however, floppym had to go and point out this isn't a perfect solution. If, in some insane world, the user has openssl:0.9.8[bindist] and openssl:0[-bindist], and tries to install openssh[bindist], portage will have it's dependancy satisfied by openssl:0.9.8[bindist] but will be linked against openssl:0. What we need to do is edit the openssh ebuilds to use best_version openssl[bindist=] when linking to openssl. I'll leave this bug open until that is done. I currently lack the skill but if no one steps up I'll try to figure it out.
I tweaked that last change with a slot dep since openssl:0.9.8 does not provide headers or .so symlinks.
This fixes the issues generating livecd's and stages for the long term I hope. In addition the logic should prevent the users from breaking themselves. Closing this bug as fixed. Thanks all.
This is not fixed yet, install-amd64-minimal-20121107.iso is still shipping an old openssh ebuild revision: # $Header: /var/cvsroot/gentoo-x86/net-misc/openssh/openssh-5.9_p1-r4.ebuild,v 1.10 2012/06/02 18:07:02 vapier Exp $
the fixes will make their way out
(In reply to comment #11) > This is not fixed yet, install-amd64-minimal-20121107.iso is still shipping > an old openssh ebuild revision: > > # $Header: > /var/cvsroot/gentoo-x86/net-misc/openssh/openssh-5.9_p1-r4.ebuild,v 1.10 > 2012/06/02 18:07:02 vapier Exp $ This was a releng (mine) issue and not a base-system issue. I'm running a new build that should have this fixed. I hope to have it in the mirrors later today.
*** Bug 444454 has been marked as a duplicate of this bug. ***
