what is the problem of Konqueror to connect with servers with a ECDSA key now supported on Fedora systems? i bet it is still the braindead rewrite of the sftp-kioslave years ago (https://bugs.kde.org/show_bug.cgi?id=236025) with dumb arguments about performance and what not while in fact recent openssh binarys support ciphers which are faster than anything supported by he broken by design libssh which restricts konqueror *useless* compared with the pipe-backend which made *any* capability of openssh visible in the sftp-client nowadays you must in fact keep a RSA key active and take care have it in known_hosts only for Konqueror - congratulations that people who point out major steps back at KDE upstream are banned :-(
and by the way "I found the problem, the kio_sftp slave supports resume now. This means it creates a new file and then overwrite the old file when the new file has been successfully uploaded. It doesn't try to change the owner and group back. I've fixed this but have to test it" is bullshit and still a step backwards - finally it means you *can not* replace a file *you own* if you do not have write permissions to the folder can somobedy throw away this crap and restore the old bheavior using openssh directly *damned*
So this is about kio_sftp, which uses libssh behind the scenes, so let's reassign this to libssh, which is where the ECDSA support is needed.
I guess a rebuild against the current OpenSSH builds may be all that's needed?
> I guess a rebuild against the current OpenSSH builds may be all that's needed? maybe, maybe the same problem as with libssh2 that it is not supported at all like it does not support a range of ciphers and so you have to verify all day long that any of your ~/.ssh/config changes are working with Konqueror too and that is why replace the kio-slave was the dumbest decision ever happend after KDE 4.0 https://bugzilla.redhat.com/show_bug.cgi?id=1019333
libssh 0.6.0rc2 already supports ECDSA and ECDH for KEX. We also implemented Curve25519 for ECDH. https://blog.cryptomilk.org/2013/09/23/ssh-ecdsa-with-curve25591/ which is also the default cipher in OpenSSH now https://blog.cryptomilk.org/2013/11/03/curve25519-sha512-is-the-default-kex-in-openssh-too-now/ libssh 0.6.0 should be released soon.
For ECDSA keys I need to update kio_sftp once libssh 0.6.0 has been released. ECDH should just work fine if you only update libssh.
> For ECDSA keys I need to update kio_sftp once libssh 0.6.0 has been released and that is why replace the kio-slave was plain wrong as well as "in future it is possible to reach a much higher transfer rate using libssh" because Library/Versus pipe is for sure not the limiting factor for network traffic and on machines without AES-NI the opposite is true at least some months ago the kio-slave did not support RC4 ciphers which are *way faster* than anything else on older machines and for LAN access where you use sftp to avoid additional software secure enough the real problem with the rewritten kio-slave is that you permanently need to make sure that whatever configuration you try to choose and working with the openssh-utilities (rsync-over-ssh, scp, sftp, ssh) does not break Konqueror
i have really enough from this braindead kio-rewrite which causes even after years that you *permanently+ have to dig in your client-configurations and verify that they are working as intented for CLI and Konqueror https://bugzilla.redhat.com/show_bug.cgi?id=1042833 throw away this crap and restore the pipe-behavior and please do not come again up with exuses about performance - the pipe in case of a networ protocol is *for sure* not the part responsible for performance
http://www.libssh.org/2014/01/08/libssh-0-6-0/ update *hardly* needed for F19/F20/F21 because it is ridiculous that after create ECDSA certificates on client and servers Konqueror insists in RSA and if known_hosts already contains the ECDSA-publick-key of the server is even too stupid to add the RSA-public-key too, you need to comment out the existing, connect one time with Konqueror and then you can place the ECDSA public-key below in known_hosts -> have fun if you work on 30 different machines with ssh/sftp all day long can we please have a update or revert this stupid kio-slave replacement which was the worst mistake after KDE4.0 to get in the future feature-support when it arrives in openssl/openssh instead different behavior and incompatible configs if someone tests them with terminal applications and later finds out the Konqueror does no longer work (cipher arcfour between testing VMs on the same host and using rsync over ssh is a good example, not long ago you where no longer able to connect to the same machine with Konqueror because the ssh_config and this would have boosted the performance much more as the kio-replacement compared to the old pipe-implementation ever could do on machines without AES-NI)
Hi Harald, Please stop harassing my colleague. You bring valid points but in a totally disrespectful way, we have simply stopped listening to your insulting rants (and we are not alone: https://www.google.com/#q=harald+reindl). Libssh makes progress to keep up with openssh features and you seem to be the only one willing to waste so much energy at destroying other's work instead of proposing or contributing constructive ways of enhancing software. Va voir chez les grecs si j'y suis. Aris
> instead of proposing constructive ways of enhancing software i proposed as the rewrite was done in a complete unfinished and unuseable state within a *stable release* to revert this and go back to pipe the sftp command of openssh as all the years before otherwise it will continue that everytime when openssl/openssh in a fedora release comes up with new features you can't use them and have a different/inconsistent behavior within the distribution > destroying other's work the problem with some of that work is that it is damaging things which where not broken before > and we are not alone and http://kparal.wordpress.com/category/fedora-qa/heroes-of-fedora-testing/ is the other side of the coin as well as these ones where a lot of packages are now hardened builds and support for ECDHE/ECDSA was much faster available in Fedora as it would have happened witout ping people - and that is what makes me terrible angry in case of the kio-slave: it wastes all my time and energy because it does not integrate welll in the rest of the distribution https://bugzilla.redhat.com/show_bug.cgi?id=319901#c108 https://bugzilla.redhat.com/show_bug.cgi?id=1019390#c3 https://bugzilla.redhat.com/show_bug.cgi?id=1019244 https://bugzilla.redhat.com/show_bug.cgi?id=1019245 https://bugzilla.redhat.com/show_bug.cgi?id=1019247 https://bugzilla.redhat.com/show_bug.cgi?id=1019249 https://bugzilla.redhat.com/show_bug.cgi?id=1019251 https://bugzilla.redhat.com/show_bug.cgi?id=1019312 https://bugzilla.redhat.com/show_bug.cgi?id=1019333 https://bugzilla.redhat.com/show_bug.cgi?id=1019337 https://bugzilla.redhat.com/show_bug.cgi?id=1019253 https://bugzilla.redhat.com/show_bug.cgi?id=1019254 https://bugzilla.redhat.com/show_bug.cgi?id=1019256 https://bugzilla.redhat.com/show_bug.cgi?id=1019259 https://bugzilla.redhat.com/show_bug.cgi?id=983604 https://bugzilla.redhat.com/show_bug.cgi?id=984181 https://bugzilla.redhat.com/show_bug.cgi?id=1008385 https://bugzilla.redhat.com/show_bug.cgi?id=983615 https://bugzilla.redhat.com/show_bug.cgi?id=1008400 https://bugzilla.redhat.com/show_bug.cgi?id=996735 https://bugzilla.redhat.com/show_bug.cgi?id=983606 https://bugzilla.redhat.com/show_bug.cgi?id=983623 https://bugzilla.redhat.com/show_bug.cgi?id=984185 https://bugzilla.redhat.com/show_bug.cgi?id=990052 https://bugzilla.redhat.com/show_bug.cgi?id=990055 https://bugzilla.redhat.com/show_bug.cgi?id=1000643 https://bugzilla.redhat.com/show_bug.cgi?id=973458
Harald is making one valid on-topic point though, that is that we should get this new libssh into Fedora as soon as possible! Can we please get that in? And then we also need kio_sftp updated to use ECDSA, per comment #6. And Harald, can we please focus on that in this bug report? I think everybody that is CCed to this bug has known from the beginning how you feel about the current ("new") libssh-based kio_sftp. Repeating that all over and over is not going to help, and to be honest, is making it LESS likely that your practical issues with it are going to get fixed. You know that I understand the reasons for your frustration (also having had my own tribulations with some rewrites, e.g. Akonadi), and you point out legitimate drawbacks of the new approach (code duplication between OpenSSH and libssh), but unfortunately, making those points here is not going to change anything about the implementation of kio_sftp. (Also, from a technical standpoint, the library really is a cleaner solution than spawning an external executable, though then it would be more consistent to also ship an SSH client using the library instead of OpenSSH. But that's also besides the point here.)
i would not get that angry if it would only not support ECDSA instead refuse connect with the additional existent RSA keypair on client and server if it finds a ECDSHA public key in known_hosts as well as for other options it does not understand a RHEL5 machine not supporting ECC at all simply writes "userauth_pubkey: unsupported public key algorithm: ecdsa-sha2-nistp521" in the logs and the openssh-client and server doing a succesful handshake with RSA while ecdsa-sha2-nistp521 is the preferred setting on the client addtitional it makes it impossible to prefer ECDSA in case of ssh-agent becaus ethat ends in enter the password for any RSA connection with Konqueror and prefer RSA in ~/.ssh/config results that even the openssh-client in combination with ssh-agent no longer use any ECDSA keys even if both sides support it, that all only to make libssh happy
> i would not get that angry if it would only not support ECDSA instead refuse > connect with the additional existent RSA keypair on client and server if it > finds a ECDSHA public key in known_hosts as well as for other options it does > not understand Instead of insulting people you should invest your time to write quality bug reports to improve libssh and kio_sftp! Pages full of rants do not fix bugs. The way you interact with people, is a way, were they simply start to ignore you, even if you have valid points. If you're a smart guy I suggest that you read the book "Team Geek". There is a chapter about you. @Kevin: I've already packaged libssh 0.6.0 for rawhide. I could do the same for f20 and f19. Could you pull the patches from kde-runtime in master and add them to the latest KDE packages? Should I open a bug for this?
I can do the patches, yes. I'll have to handle them separately for Rawhide (kde-runtime-4.12.0, 4.12.1 being imported right now) and F19/F20 (kde-runtime-4.11.5, already in stable for F20, going to stable for F19 soon), but it should be straightforward. For F19 and F20, I will also need buildroot overrides for libssh 0.6.0, but as a provenpackager, I think I can set them myself, I just need the build to be available. I can also take care of pushing the grouped updates in Bodhi.
Thanks for your help and the coordination Kevin!
I'm taking care of the grouped updates.
kde-runtime patches imported, building now. (For Rawhide, it's already all built.)
libssh-0.6.0-1.fc20,kde-runtime-4.11.5-2.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/libssh-0.6.0-1.fc20,kde-runtime-4.11.5-2.fc20
thanks, i have to wait for a kde-unstable update because i use KDE 4.12 from Rex on my Desktopmachines with kde-runtime-4.12.0-1.fc20.x86_64
libssh-0.6.0-1.fc19,kde-runtime-4.11.5-2.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/libssh-0.6.0-1.fc19,kde-runtime-4.11.5-2.fc19
@Harald Reindl: KDE 4.12.1 is being imported right now, Rex Dieter will build it for F20 kde-unstable ASAP, and our build (kde-runtime-4.12.1-1) will include the backport (any kde-runtime ≥ 4.12.0-2 resp. 4.11.5-2 has the backport). So just give us a couple more days. (If you really need the fix NOW, you can rebuild the kde-runtime-4.12.0-2 SRPM from Rawhide.)
@Kevin: thanks for the information, 4.12.1 sounds good, i am using the kde.unstable packages since they are first built for my daily work and besides the in the meantime fixed bug caused by build-requirements ending in okular no longer displaying png/jpg/gif but only pdf i see no regressions
Package libssh-0.6.0-1.fc20, kde-runtime-4.11.5-2.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 libssh-0.6.0-1.fc20 kde-runtime-4.11.5-2.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-0660/libssh-0.6.0-1.fc20,kde-runtime-4.11.5-2.fc20 then log in and leave karma (feedback).
libssh-0.6.0 and the latest kde-updates (in my case 4.12.1 from kde-unstable) fixes ECDSA while also connect to machines not supporting it is fine KDE-autostart: Exec=/usr/bin/ssh-add ~/.ssh/id_ecdsa ~/.ssh/id_rsa however, connect to a RHEL5 machine with konqueror and enabled compression results in "kex error: no match for method compression algo client -> server: server [none], client [zlib,zlib] while i am not 100% sure that this was not also the case before 0.6.0 since i do not connect that often to the VMware-data-recvervy appliance running on CentOS5, that may break interoperability to other sshd servers too and is no problem with the sftp/ssh command line tools of openssh
If you discover a bug in libssh, please open a bug report at https://red.libssh.org/ A good description how to report bugs can be found here: http://www.chiark.greenend.org.uk/~sgtatham/bugs.html Please add the excapt version of the CentOS version it isn't working against and also OpenSSH version. A log file of libssh often helps too. You can find how to turn on log messages of libssh at: http://techbase.kde.org/Development/Tutorials/Debugging/Debugging_IOSlaves/Debugging_kio_sftp It also describes how to activate verbose logging on the openssh server.
Hi Harald, Your server doesn't support compression. libssh ensures that when you have compression enabled the data stream is actually compressed.
> Your server doesn't support compression that's true, but sftp/ssh CLI switches to uncompressed in that case if i would not use rsync/sftp/ssh with that machine all the time that would be something different compared to only Konqueror refuses to connect
libssh-0.6.0-1.fc19, kde-runtime-4.11.5-2.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
libssh-0.6.0-1.fc20, kde-runtime-4.11.5-2.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.