Bug 1186198

Thank you very much for your bug report.

From comment #1 it looks like you are an export in parsing config files. I'm sure that the libssh project would be grateful, if you send a patch which parses the ssh_config file in a manner, you think, is the correct way to do it.

sadly i am not a c-programmer

the real problem is *hey do parse it* because otherwise they would not mention only the unsupported "aes128-gcm" in the error message, but the reason for the comma seperated value is to say "fine, i look if i can handle one of the next" and not stop at the first one

the intention of multiuple ciphers in the configuration is to order them by security-level and/or performance depending on the environment and give any consumer of the configuration so a preferred order and the opportunity to fallback to the first supported in the list

From the description:
> so take the next one damend - is it really *that* difficult?

Why don't you learn C and try to find out?

From comment #2:
> the real problem is *hey do parse it* because otherwise they would not mention 
> only the unsupported "aes128-gcm" in the error message, but the 
> reason for the comma seperated value is to say "fine, i look if i can handle 
> one of the next" and not stop at the first one

Awesome, it sounds like you already know what needs to be done to fix the problem. I'm looking forward to a patch.

> Why don't you learn C and try to find out?

are you doing my other work in the meantime

> Awesome, it sounds like you already know what needs 
> to be done to fix the problem. I'm looking forward 
> to a patch.

awesome, all that problems did not exist for decades until someone did a re-write of the kio-slave breaking anything left and right and even argue about better performance with libssh compared to the previous pipe-call not realize that this is pure nonsense in context of doing compression, encryption and blow the data over a network

I suggest you both refrain from commenting or referring to each other rather than the issue at hand.  It's clear that's not constructive (nor welcome) at this point.

As a reminder,
https://fedoraproject.org/w/index.php?title=Community_working_group/Code_of_Conduct&oldid=277209

rebasing as FutureFeature

as i reported that KDE is unusable with ECDSA configs i was told "but libssh supports the upcoming ED25519" - no it does not years later

the same mess as with ciphers for ED25519 host keys (having them in known_hosts from openssh clients results in KDE no longer connect to the host) and using a ED25519 also fails 

it's such a mess that you can't update anything ssh related in a safe way without play around with orderings in known_hosts or just disable ciphers and key-types until both, openssh clients and KDE continue to work 

having in that game non-fedora machines on the server side finally raises the question of sanity for some developer decisions like throw away working things without a useable replacement

Ciphers aes128-gcm,aes256-gcm,aes128-ctr,aes256-ctr,aes256-cbc

still broken with F23, sad enough that GCM is not supported because it's the fastest implementation on AES-NI CPU's but fail instead try to use a different one from the list (which is the whole purpose of list more than one) is a epic fail - you can happily use the ciphers above on any system as long KDE is not part of the game

at least ED25519 host keys are working now

This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '23'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 23 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

http://blog.cryptomilk.org/2013/09/23/ssh-ecdsa-with-curve25591/

curve25519-sha256 don't help much when you need to connect to a openssh server and both sides need to agree about ciphers and KDE users can't place  aes128-gcm@openssh because the libssh-kioslave is still too dumb to at least fall back to the next cipher if he don't understand the first and so *any* application is using woser crypto just because of your unability to handle "Ciphers aes128-gcm,aes256-gcm,aes128-ctr,aes256-ctr,aes256-cbc" proper

This message is a reminder that Fedora 24 is nearing its end of life.
Approximately 2 (two) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 24. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '24'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 24 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

Created attachment 1317731 [details]
Only set the supported ciphers internally

UPSTREAM BUG: https://bugs.libssh.org/T37

with F26 "Ciphers aes128-gcm,aes256-gcm,aes128-ctr,aes256-ctr,aes256-cbc" in /etc/ssh/ssh_config finally worked

after upgrade to F27 in Konqueror again:
Die Webseite unter error:/?error=163&errText=crypt_set_algorithms2%3A no crypto algorithm function found for aes128-gcm%40openssh.com#sftp://reindl@localhost:10022/ ist möglicherweise vorübergehend nicht verfügbar oder wurde dauerhaft an eine neue Webadresse verschoben.
ERR_UNKNOWN_URL_SCHEME

it makes me simply sick that years after the rewirte of the kio-slave that all is still kidding around

Hello,

Could you please check if this is working for you in Fedora 29?

no because F29 is far outside my scope given all the issues with kernel 4.19.x on F28 forcing me to stay on the latest F27 4.18.20 build

and what is that hard to reproduce this?

/etc/ssh/ssh_config:
Ciphers aes128-gcm,aes256-gcm,aes128-ctr,aes256-ctr,aes256-cbc

just place a cipher not supported by libssh2 on the left side
don't get me wrong but i expect that developers are capable to automate this and put it in automatic tests fpr future proof

(In reply to Harald Reindl from comment #17)
> and what is that hard to reproduce this?
> 
> /etc/ssh/ssh_config:
> Ciphers
> aes128-gcm,aes256-gcm,aes128-ctr,aes256-ctr,aes256-
> cbc
> 
> just place a cipher not supported by libssh2 on the left side
> don't get me wrong but i expect that developers are capable to automate this
> and put it in automatic tests fpr future proof

Thanks for the suggestion, we have a test case for this included in our tests.
I would like to inform you that this is supported in Fedora 28 and 29, if you are still interested.
Unfortunately, Fedora 27 is in EOL, so this will not be back ported.