When connecting to my webserver, putting in dolphins address-line: sftp://username@domain/directory dolphin displays the username/password dialog (username set, password empty although saved in Kwallet). I enter the password and dolphin says "incorrect password". If Iput sftp://username:password@domain/directory the connection works normally. So something goes wrong with the password verification process of dolphin and/or the communication with Kwallet... Until the last update to the recent version I never had this problem, so I guess it is not related to bug 269095??? kind regards Daniel opensuse 12.1, KDE 4.8.3, dolphin 4.8.3-294.1. Reproducible: Always Steps to Reproduce: 1. enter sftp://username@domain/directory in doplhin, try to connect 2. enter the correct password: connection fails Actual Results: dolphin says, username/password are not correct, although they are Expected Results: connection with the server, display of directory contents
note: "fish" and "ftp" works, only "sftp" does not...
I can confirm this bug, fedora 16 kde, 64bit all latest updates same problem, rejects known good passwords when connection via dolphin and sftp.
It happens to me too (kde 4.8.3 in Gentoo). I would add that if I don't specify the port, it seems to ask for port 0 in the login dialog (sftp://foo:0), but manually adding :22 doesn't help either. Why do you guys keep breaking sftp, again and again?!
https://git.reviewboard.kde.org/r/104642/
I can't connect to any SFTP server, where /etc/ssh/sshd_config contains "PasswordAuthentication no". And since this is the default in virtually all of my servers, I can't use them anymore. Fix it, please! Commenting out "PasswordAuthentication no" on the server side circumvents the problem, but I wouldn't like to do that. Fix it in 4.8.4, please!!!!
Created attachment 71659 [details] Patch to kioslave/sftp/kio_sftp.cpp to use QString instead of const char * and use info.password instead of mPassword The attached patch solves the problem on my KDE 4.8.3 installation (FreeBSD port). The patch consists of two modifications, both into sftpProtocol::authenticateKeyboardInteractive(), file kio_sftp.cpp 1- the password is taken from the "info" parameter, instead of the private class attribute "mPassword". That attribute is only initialized once (I guess when parsing the URL, and that's why the syntax sftp://user:password@host works), while the "info" parameter is initialized by a KPasswordDialog, and thus contains the password. 2- the variable "answer" is declared as QString instead of const char*, as it is IMHO safer. The current code creates and destroy a QByteArray object, and assigns its "constData" to answer. If I understood correctly, that memory could be overwritten at any time, because the QByteArray is immediately freed after creation. After the patch, the correctness of the buffer is ensured, because the QByteArray is only destroyed when each call returns.
Still not fixed in 4.8.4!!!
*** This bug has been confirmed by popular vote. ***
Created attachment 71857 [details] Updated patch I'm not a kde-runtime maintainer, but here are my thoughts on the patch. The patch does indeed make things much safer, since the old method, as you mentioned, stores the pointer to the location of the data of a temporary QByteArray. With the old method you definitely aren't guaranteed that nothing will step on that data before it is finished being used within the function. But while it is much safer, it still passes the address of a temporary to ssh_userauth_kbdint_setanswer(), since calling toUtf8() on a QString returns a temporary (in this case) copy of the string as a byte array, e.g.: + if (ssh_userauth_kbdint_setanswer(mSession, i, answer.toUtf8().constData()) < 0) { Depending on how ssh_userauth_kbdint_setanswer is implemented, it may or may not be "fine" to do this, (It does indeed solve the problem in your testing) but it still does leave the code to maybe failing at least some of the time. It would be better to make "answer" a QByteArray rather than a QString. That way, when you initially assign it with "answer = info.username.toUtf8()", you have an instance of the byte array that will be kept around for all of the current scope. You can then grab its constData() safely, knowing that the memory there will remain unchanged for the life of "answer". I've attached an updated version of the patch that reflects these changes.
*** Bug 269095 has been marked as a duplicate of this bug. ***
Jonathan, thank you for updating the patch! I can confirm that your patch fixes the problem when applied to KDE 4.8.4 sources (FreeBSD port was updated since my last report).
First I want https://git.reviewboard.kde.org/r/104642/ to be in before submitting the attached patch.
Created attachment 72007 [details] Logging of kio_sftp after applying diff from review request 104642 on KDE 4.8.4, FreeBSD This is the logging output of kio_sftp after applying https://git.reviewboard.kde.org/r/104642/diff/raw/ and trying to connect to sftp://127.0.0.1 The outcome is: no password request window is shown. The connection times out after some time (pointed out in the log).
(In reply to comment #13) > Created attachment 72007 [details] > Logging of kio_sftp after applying diff from review request 104642 on KDE > 4.8.4, FreeBSD By going through the patched code, I may have spotted the cause of the problem. Inside sftpProtocol::openConnection() the first call to openPasswordDialog() is only _after_ calling sftpProtocol::authenticateKeyboardInteractive(). And sftpProtocol::authenticateKeyboardInteractive() itself does not call openPasswordDialog(), unless there is an unknown prompt from the server. I am sorry I don't know how to fix this... HTH anyway.
I'm not sure if it is directly related to this bug, but I have been having the same problem as Tamás Németh (and it's mentioned in the link Arrigo Marchiori posted). I use public key authentication and I can connect to the server just fine the first time, but after a while (usually if I try to connect more than once in a short period of time), it appears to time out and I get an "Authentication Failed" message after about 30 seconds on every subsequent attempt. The only way to have it prompt me for the password to unlock the private key is if I reboot the computer or wait around 30 minutes and try again. I would assume that it somehow can't access the key's password and instead of prompting for it again, it moves on to the next public key. I have been having this same problem on two separate computers for probably 6-8 months now. kio_sftp(4782) kdemain: *** Starting kio_sftp kio_sftp(4782) sftpProtocol::sftpProtocol: pid = 4782 kio_sftp(4782) sftpProtocol::sftpProtocol: debug = kio_sftp(4782) sftpProtocol::setHost: "" @ "mayan" : 0 kio_sftp(4782) sftpProtocol::closeConnection: kio_sftp(4782) sftpProtocol::stat: KUrl("sftp://mayan") kio_sftp(4782) sftpProtocol::openConnection: username= "" , host= "mayan" , port= 0 kio_sftp(4782) sftpProtocol::openConnection: checking cache: info.username = "" , info.url = "sftp://mayan" kio_sftp(4782) sftpProtocol::openConnection: Creating the SSH session and setting options kio_sftp(4782) sftpProtocol::openConnection: Trying to connect to the SSH server kio_sftp(4782) sftpProtocol::openConnection: Getting the SSH server hash kio_sftp(4782) sftpProtocol::openConnection: Checking if the SSH server is known kio_sftp(4782) sftpProtocol::openConnection: Trying to authenticate with the server kio_sftp(4782) sftpProtocol::openConnection: Trying to authenticate public key kio_sftp(4782) sftpProtocol::openConnection: Trying to authenticate with password kio_sftp(4782) sftpProtocol::openConnection: Trying to authenticate public key kio_sftp(4782) sftpProtocol::openConnection: Trying to authenticate with password kio_sftp(4782) sftpProtocol::openConnection: Trying to authenticate public key kio_sftp(4782) sftpProtocol::openConnection: Trying to authenticate with password kio_sftp(4782) sftpProtocol::openConnection: Trying to authenticate public key kio_sftp(4782) sftpProtocol::openConnection: Trying to authenticate with password kio_sftp(4782) sftpProtocol::openConnection: Trying to authenticate public key kio_sftp(4782) sftpProtocol::openConnection: Trying to authenticate with password kio_sftp(4782) sftpProtocol::openConnection: Password authentication failed: "Received SSH_MSG_DISCONNECT: 33554432:Too many authentication failures for Passphrase for private key" kio_sftp(4782) sftpProtocol::closeConnection: kio_sftp(4782) sftpProtocol::sftpConnect: connected ? false username: old= "" new= "" kio_sftp(4782) sftpProtocol::closeConnection: kio_sftp(4782) kdemain: *** kio_sftp Done kio_sftp(4782) sftpProtocol::~sftpProtocol: pid = 4782 kio_sftp(4782) sftpProtocol::closeConnection:
*** Bug 302735 has been marked as a duplicate of this bug. ***
it happens also on Fedora KDE 16/17
I use Kate for remote file editing over SFTP, same problem after upgrading to KDE 4.8.4. Password is not recognized.
(In reply to comment #14) > (In reply to comment #13) > > Created attachment 72007 [details] > > Logging of kio_sftp after applying diff from review request 104642 on KDE > > 4.8.4, FreeBSD > > By going through the patched code, I may have spotted the cause of the > problem. > > Inside sftpProtocol::openConnection() the first call to openPasswordDialog() > is only _after_ calling sftpProtocol::authenticateKeyboardInteractive(). And > sftpProtocol::authenticateKeyboardInteractive() itself does not call > openPasswordDialog(), unless there is an unknown prompt from the server. > > I am sorry I don't know how to fix this... HTH anyway. The patch in the review ticket is one iteration less than the patch that was committed. The committed patch will prompt you for password in the ::authenticateKeyboardInteractive() function and that patch has been tested for all the scenarios listed in the review ticket. IOW, you should not have any of these problems in KDE 4.9 series. The patch cannot be back ported for a couple of reasons. It contains new strings and it uses a feature in the password server that is not available in the KDE 4.8 series.
(In reply to comment #12) > First I want https://git.reviewboard.kde.org/r/104642/ to be in before > submitting the attached patch. Is Jonathan's patch still needed after Dawit's actual commit to kde-runtime? Is there anything left here that prevents this bug from being closed?
(In reply to comment #20) > (In reply to comment #12) > > First I want https://git.reviewboard.kde.org/r/104642/ to be in before > > submitting the attached patch. > > Is Jonathan's patch still needed after Dawit's actual commit to kde-runtime? > Is there anything left here that prevents this bug from being closed? No. It should be closed and the reporter can reopen if the issue is not resolved for him in KDE 4.9.0 or higher.
I am having this problem on Debian KDE 4.14.2 (Debian "testing" jessie). I am using public key authentication and I can connect fine by the command line, but not in KDE apps: $ sftp -v mayan OpenSSH_6.7p1 Debian-3, OpenSSL 1.0.1k 8 Jan 2015 debug1: Reading configuration data /home/username/.ssh/config debug1: /home/username/.ssh/config line 1: Applying options for mayan debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: Applying options for * debug1: Hostname has changed; re-reading configuration debug1: Reading configuration data /home/username/.ssh/config debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: Applying options for * debug1: Connecting to hostname.example.com [xxx.xxx.xxx.xxx] port yyyy. debug1: Connection established. debug1: identity file /home/username/.ssh/mayan type 2 debug1: key_load_public: No such file or directory debug1: identity file /home/username/.ssh/mayan-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.7p1 Debian-3 debug1: Remote protocol version 2.0, remote software version OpenSSH_6.0p1 Debian-4+deb7u2 debug1: match: OpenSSH_6.0p1 Debian-4+deb7u2 pat OpenSSH* compat 0x04000000 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-ctr umac-64@openssh.com none debug1: kex: client->server aes128-ctr umac-64@openssh.com none debug1: sending SSH2_MSG_KEX_ECDH_INIT debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: Server host key: RSA 5f:93:7f:63:6f:b3:e7:df:b7:1a:c3:9c:82:ff:b5:65 debug1: Host '[hostname.example.com]:yyyy' is known and matches the RSA host key. debug1: Found key in /home/username/.ssh/known_hosts:1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: Roaming not allowed by server debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey debug1: Next authentication method: publickey debug1: Offering DSA public key: /home/username/.ssh/mayan debug1: Server accepts key: pkalg ssh-dss blen 434 debug1: key_load_private_type: incorrect passphrase supplied to decrypt private key Enter passphrase for key '/home/username/.ssh/mayan': debug1: Authentication succeeded (publickey). Authenticated to hostname.example.com ([xxx.xxx.xxx.xxx]:yyyy). debug1: channel 0: new [client-session] debug1: Requesting no-more-sessions@openssh.com debug1: Entering interactive session. debug1: Sending environment. debug1: Sending env LANG = en_US.UTF-8 debug1: Sending subsystem: sftp Connected to mayan. sftp> When trying to connect with KDE apps, I get a message telling me to enter the passphrase to unlock the private key and when I enter it, it immediately says that authentication failed. One workaround if anyone else is having this problem is to install the "ssh-agent-filter" package and then execute "ssh-add /path/to/private_key"