Version: (using KDE 4.4.2) Installed from: RedHat RPMs Seems that no developer is using sftp in konqueror because since 4.4.2 including 4.4.3 it is COMPLETLY broken. Seems like anybody has rewritten the whole kio-slave from scratch and was thinking there are only user,host,port22-configs in the real life. Some of these bugs arte introduced before 4.4.2 and 4.4.2 seems to make them perfect ________________________________ 1) If your Private-Key allows some users and root on the target machine and you use sftp://user@host/ you will always use root without knowing this because jonqueror shows all the time the user you wanted. You realize this only if sftp-chroot is active on the host and a folder from your bookmarks will not be found, after looking in /var/log/secure on the server you know why :-( ________________________________ 2) If "MaxAuthTries 1" is set on the server there is no way to login, you must allow two auth-tries, this was not so in the past ________________________________ 3) If you open a file on the server as root with kate and save the changes owner/group is root what means that we are speaking from a webserver and you change a configuration-file the wohle website is dead. This heavy bug is since kde 4.4 You NEVER have to change owner/group/permissions while edit a existing file ________________________________ 4) If you have more sshd on a host on different ports (vmware-machines behind NAT with port forwarding on the host as sample) and in your "known_hosts" are entrys since years for thsi connections it will fail now because kde will use the wrong line from "known_host", mean it will use the line for the host himself instead the one with the port you use what means that verification fails a workaround for me was copy the ssh-host-keys in each virtual machine so that there is all time the same, but this worked over years fine even with kde3 and with 4.4 it was destroyed
The same bugreport in the Fedora-Bugzilla in the hope that a possible fix upstream or in fedora reachs btoh as soon as possible https://bugzilla.redhat.com/show_bug.cgi?id=588050
There are several thousand users out there and each user has different setup and use cases for sftp. It isn't possible to test all of them or know about them. If you want help and get bugfixes please file a separate bug report for each issue and describe how to reproduce them. If you need support for more ssh_config options please file bug reports against libssh at http://dev.libssh.org/ Issue number 3 should be fixed with the next KDE release. Issue number 4 has been fixed lately in libssh and will be supported in the next release of libssh.
> There are several thousand users out there and each user has different > setup and use cases for sftp. Yes > It isn't possible to test all of them or know > about them. No, that all worked over years and was damaged with 4.4 > If you want help and get bugfixes please file a separate bug > report for each issue and describe how to reproduce them. What sense should this make We are speaking about the same kio which worked sure from the year 2006 until KDE 4.4 > If you need support for more ssh_config options please file > bug reports against libssh at http://dev.libssh.org/ I do not want anything MORE, i want the same behavior KDE 4.3 had > Issue number 3 should be fixed with the next KDE release. Uff, this is a long time > Issue number 4 has been fixed lately in libssh and will be > supported in the next release of libssh. Strange, this worked all the years and i wonderd why i can not connect any longer to my virtual machines until i found out that KDE is using the wrong host-key from "known_hosts"
The kio slave has been rewritten based on libssh. The old slave executed the ssh binary and used a pipe to talk to the process. The slave implemented it's own sftp protocol. With libssh the code is much cleaner and in future it is possible to reach a much higher transfer rate using libssh. The downside is that libssh lacks of some functionality some power users expect. We need to implement them. There was no sftp maintainer anymore and calling the binary cause trouble due to changes in Qt. Instead of arguing here we should fix the bugs, but I can only do that if I can reproduce it.
> Issue number 3 should be fixed with the next KDE release. Define "next"? 4.4.3? 4.4.4? 4.5.0?
> With libssh the code is much cleaner and in future > it is possible to reach a much higher transfer rate Well, but "in future" helps nobody > using libssh. The downside is that libssh lacks of > some functionality some power users expect. We need to implement them. So why in the world do you not first implement them and after that switch? It does not help users and it does not help the acceptance of kde and other free software that users have to fear every update because working things are replaced permanently with other backend-layers and after that working over months and years to get back to the stability the things had before For KDE4 the time is NOW to get lost problems and weak implementations making endusers crazy since years instead begin switch the next layers with introducing new troubles - The same happens in many other free software and i love to help and test over the years But sometimes are points reached where i do not understand why in the world things where developers know that they are not ready instead make them fine in background an d let endusers in peace with working softwware - possible speed does help no one if it will not work at the end, it can be a little slower if it is rock stable Please be a little more careful upstream with experiments and move your focus to get all the features from KDE3 back instead of lost new ones and stop everytime things starts to work searching replacemnets for them, in this way we never ever get really working software
Issue 1: I still don't understand this issue. There was a bug with parsing the config file, this is fixed in KDE 4.4.3. Issue 2: We try to auth with pubkey first and then go to keyboard-interactive mode. So you probably have a default public key in your ~/.ssh directory which is used to try a public key auth. Issue 3: This should be fixed with KDE 4.4.3. Issue 4: Has been fixed, we will release a new libssh version this week.
> Issue 2: > We try to auth with pubkey first and then go to keyboard-interactive > mode. So you probably have a default public key in your ~/.ssh directory which > is used to try a public key auth. I have a default public key and this one is allowed if set "MaxAuthTries 1" it will fail, this was not so in the past Below the sshd-configuration, it needs minimum 2 tries [root@arrakis:~]$ cat /var/log/secure May 10 11:22:15 arrakis sshd[24507]: Disconnecting: Too many authentication failures for root ____________________ Port 22 Protocol 2 AddressFamily inet ListenAddress 0.0.0.0 SyslogFacility AUTHPRIV PasswordAuthentication no ChallengeResponseAuthentication no GSSAPIAuthentication no GSSAPICleanupCredentials no X11Forwarding yes RSAAuthentication yes PubkeyAuthentication yes PermitEmptyPasswords no PermitRootLogin without-password AllowGroups root gateway nx sftp-users apache AllowUsers root gateway nx reindl peter ingo stock IgnoreRhosts yes HostbasedAuthentication no StrictModes yes UseDNS no AllowTcpForwarding yes TCPKeepAlive yes KeepAlive yes UsePrivilegeSeparation yes Compression yes UsePAM yes LoginGraceTime 30 MaxAuthTries 1 MaxStartups 15 AuthorizedKeysFile .ssh/authorized_keys2
> Issue 3: This should be fixed with KDE 4.4.3 No, it is not fixed May 10 11:26:50 arrakis httpd: PHP Warning: require(/Volumes/dune/www-servers/rhsoft.net/www.rhsoft.net/cms.ini.php) [<a href='http://at.php.net/manual/de/function.require.php'>function.require.php</a>]: failed to open stream: Permission denied in /Volumes/dune/www-servers/rhsoft.net/www.rhsoft.net/config.inc.php on line 200 [root@arrakis:~]$ stat /Volumes/dune/www-servers/rhsoft.net/www.rhsoft.net/cms.ini.php File: „/Volumes/dune/www-servers/rhsoft.net/www.rhsoft.net/cms.ini.php“ Size: 30011 Blocks: 64 IO Block: 4096 reguläre Datei Device: 851h/2129d Inode: 65740 Links: 1 Access: (0660/-rw-rw----) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2010-05-10 11:26:46.291173975 +0200 Modify: 2010-05-10 11:26:46.310242864 +0200 Change: 2010-05-10 11:26:46.331547133 +0200 Owner/User was "apache" before open with kate over konqueror/sftp So chmod is ok, but owner/group chnages to root while eidt as root over kate [harry@nb-rhsoft:~]$ rpm -qa | grep kde | grep sdk kdesdk-utils-4.4.3-1.fc12.1.x86_64 kdesdk-4.4.3-1.fc12.1.x86_64 kdesdk-libs-4.4.3-1.fc12.1.x86_64
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.
If most of the issues are upstream issues, bigfoot bugs or issues with lack of information I will close this as invalid. Most of them should be fixed with libssh 0.4.3 which will be released by the end of the week. If you want bugs fixed, please file a bug report for EACH issue with enough information how to reproduce them or logs to fully understand the problem.
OK, to make it easier for both of us i will wait until hopefully libssh-update comes from kde-testing (fedora) and take a look if and which are not resolved
tried both libssh / kioslaves from trunk and it just doesn't work, no directory listing is done :( this is a thing i depend on daily base and i just can't understand why one drops a working version and replaces it with a unstable - the right way would be to test the new stuff and keep the working solution until a switch can be done.
> the right way would be to test the new stuff and keep the > working solution until a switch can be done. That is right and the reason why it is ugly that we should open a bugreport for each piece of this crap. It should never happen that since years working subsystems are changed against an pre-alpha and released Especially for KDE4-Parts KDE4 is still long away to get the usabilty and bugfree-state of KDE3 and instead working on real problems some people are searching ways to create new ones
the only thing i could find was this in the serverlog: May 19 14:38:01 server sshd[10319]: error: ssh_msg_send: write i get prompted if the fingerprint is ok and i want to connect, user/pass dialog pops up and then it stalls
This bug is closed. There are several reasons for closing this bug. Please be so kind and read http://www.chiark.greenend.org.uk/~sgtatham/bugs.html then open a new bug report. Thanks.
So restore the old subsystem, write a new one in trunk and AFTER TESTING make a release, what happens here is laughable - The whole kio-slave is buggy like hell and instead of testing BEFORE release the users should open many different bugreports? This is not the way software development works and opensource is not a valid reason for release pre-alpha software and call it stable
Please file separate bug reports for your separate issues, as both I (first, in the Fedora bug report) and Andreas Schneider (see comment #11) have been telling you.
WHY in the world do you make reporters the life so hard? I make my money with software-development and have no understanding for this because it makes really no sense to get 5 bugreports in the same software-part from the same reporter. It makes it also others harder to find "hey there is one report for two of my problems and i have to watch only what happens in this one" Do you think if have no other work as dealing with bugreporting? Fact is that somebody did rewrite the kio-slave who had no plan and is using a library which is also not ready for realse as i understand some answers in this report
Separate issues need to be fixed separately, so we need to track them separately. They might not even be in the same component, i.e. some bugs are in the kioslave itself, others in libssh.
That is right, but why do you treat the endusers which are trying to help instead of open the seperate bugs and linking here? This is simply not fair! Life could be so easy if some people trying more to take the help from users instead of claim more and more from them. My initial bugreport is very clear and simple for every one which is using ssh/sftp and this here feels like the developer does not himself which leaves a bad taste in my mouth
This is my last comment to this bug. 1) This is the behaviour specified in the RFC. 2) Your setup is broken and worked by chance with the previous version. 3) Fixed. 4) Fixed.
3) Fixed. THANK YOU, i hope there comes a fedora-package soon 4) Fixed. THANK YOU, i hope there comes a fedora-package soon ________________________________ > 1) This is the behaviour specified in the RFC. In what RFC should this be specified? * I have a private key * This key is allowed for "harry@targethost" and "root@target host" if i use "sftp://harry@targethost" i should not be connected as "root" while kde shows me the whole time i am connected as "harry" and this is sure not the correct behavier because that would mean you can not connect with limited permissions if you are root on a machine and it is sure not the correct behaviour to show the wrong user in KDE. What sense should make specify the username if it is ignored and why does "ssh harry@targethost" work? What you say is that the openssh-client is broken because it does what the user say and all kde-releases before were broken because they also did > 2) Your setup is broken and worked by chance with the previous version. OK, this is a little bug which has the simple workaround to allow two auth-tries on the server But my etup is not broken as long as cli-clients can connect with one try and kde 4.3 also had no problem
I agree that 1) is a bug, though I haven't seen this myself because I don't have such a setup. It should use the explicitly specified user, even if the private key also works for root. I have noticed what I strongly suspect is issue 2) myself and I'm not root on that server so I can't change the server configuration. And previous versions handled that server perfectly. I wonder whether 1) and 2) might actually be the same bug, i.e. libssh trying to log in as root first and then as the user being asked for? (But that might be a totally wrong guess, I haven't actually looked at the code.)
1) is fixed with today package from kde-redhat-testing May 20 12:31:52 Updated: libssh-0.4.3-1.fc12.x86_64 ___________ 2) is still alive * MaxAuthTries 1 * no connect * MaxAuthTries 2 * works This is independent from the user and happens also with root For me it is no problem, but maybe for some others which are not in the position to change this value on the sshd