Bug 236025

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