Bug 1186198 - RFE: learn to parse ssh_config
Summary: RFE: learn to parse ssh_config
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: libssh
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Andreas Schneider
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords: FutureFeature
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-01-27 09:52 UTC by Harald Reindl
Modified: 2018-12-10 16:55 UTC (History)
7 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2018-12-10 16:55:30 UTC


Attachments (Terms of Use)
Only set the supported ciphers internally (9.75 KB, patch)
2017-08-24 14:34 UTC, Nikos Mavrogiannopoulos
no flags Details | Diff

Description Harald Reindl 2015-01-27 09:52:06 UTC
Konqueror: crypt_set_algorithms2: no crypto algorithm function found for aes128-gcm@openssh.com and no connection possible

/etc/ssh/ssh_config:
Ciphers aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-ctr,aes256-ctr,aes256-cbc

so take the next one damend - is it really *that* difficult?

each time openssh introduces new ciphers or key types KDE io-slaves are breaking after the stupidity years ago re-write them using libssh instead pipes to the openssh-client programs - that's unacceptable if the library is unable to work with easy to parse configurations

Comment 1 Andreas Schneider 2015-01-27 11:17:40 UTC
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.

Comment 2 Harald Reindl 2015-01-27 11:42:42 UTC
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@openssh.com" 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

Comment 3 Andreas Schneider 2015-01-27 13:57:55 UTC
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@openssh.com" 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.

Comment 4 Harald Reindl 2015-01-27 14:05:35 UTC
> 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

Comment 5 Rex Dieter 2015-01-27 14:26:45 UTC
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

Comment 6 Rex Dieter 2015-01-27 14:27:31 UTC
rebasing as FutureFeature

Comment 7 Harald Reindl 2015-03-24 15:58:26 UTC
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

Comment 8 Harald Reindl 2015-11-11 13:32:35 UTC
Ciphers aes128-gcm@openssh.com,aes256-gcm@openssh.com,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

Comment 9 Fedora End Of Life 2016-11-24 11:23:31 UTC
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.

Comment 10 Harald Reindl 2016-12-17 13:02:44 UTC
http://blog.cryptomilk.org/2013/09/23/ssh-ecdsa-with-curve25591/

curve25519-sha256@libssh.org 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@openssh.com,aes256-gcm@openssh.com,aes128-ctr,aes256-ctr,aes256-cbc" proper

Comment 11 Fedora End Of Life 2017-07-25 18:49:03 UTC
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.

Comment 12 Nikos Mavrogiannopoulos 2017-08-24 14:34 UTC
Created attachment 1317731 [details]
Only set the supported ciphers internally

Comment 13 Andreas Schneider 2017-08-24 16:10:36 UTC
UPSTREAM BUG: https://bugs.libssh.org/T37

Comment 14 Harald Reindl 2018-01-22 16:00:59 UTC
with F26 "Ciphers aes128-gcm@openssh.com,aes256-gcm@openssh.com,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

Comment 15 Anderson Sasaki 2018-12-10 15:28:27 UTC
Hello,

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

Comment 16 Harald Reindl 2018-12-10 15:42:21 UTC
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

Comment 17 Harald Reindl 2018-12-10 15:44:26 UTC
and what is that hard to reproduce this?

/etc/ssh/ssh_config:
Ciphers aes128-gcm@openssh.com,aes256-gcm@openssh.com,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

Comment 18 Anderson Sasaki 2018-12-10 16:55:30 UTC
(In reply to Harald Reindl from comment #17)
> and what is that hard to reproduce this?
> 
> /etc/ssh/ssh_config:
> Ciphers
> aes128-gcm@openssh.com,aes256-gcm@openssh.com,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.


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