sftp connection with password fails

[Arrigo Marchiori]

It is not possible to access a sftp:// URL using Dolphin, if the password is not specified on the URL itself.

This bug has been reported upstream: https://bugs.kde.org/show_bug.cgi?id=299993
There is a patch there, but it seems that upstream did not test it yet.

This problem is encountered on Precise Pangolin, updated to yesterday (June 11th).

[B5cej-linux (b5cej-linux)]

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

[B5cej-linux (b5cej-linux)]

note:
"fish" and "ftp" works, only "sftp" does not...

[Tim-thawkins (tim-thawkins)]

I can confirm this bug,

fedora 16 kde, 64bit all latest updates

same problem, rejects known good passwords when connection via dolphin and sftp.

[aditsu (aditsu)]

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?!

[3-asn (3-asn)]

https://git.reviewboard.kde.org/r/104642/

[Tamás Németh (nice)]

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!!!!

[Arrigo Marchiori (ardovm)]

Created attachment 71659
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.

[Tamás Németh (nice)]

Still not fixed in 4.8.4!!!

[Arrigo Marchiori (ardovm)]

The attached patch, when applied to the source of the kde-runtime-4.8.3 package, fixes the problem.
It is the same patch reported to upstream, with different file paths.

[Arrigo Marchiori (ardovm)]

*** This bug has been confirmed by popular vote. ***

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "Patch for sources of kde-runtime-4.8.3" of this bug report has been identified as being a patch. The ubuntu-reviewers team has been subscribed to the bug report so that they can review the patch. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-reviewers team please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

[Jonathan Thomas (echidnaman)]

Created attachment 71857
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.

[Jonathan Thomas (echidnaman)]

*** Bug 269095 has been marked as a duplicate of this bug. ***

[Arrigo Marchiori (ardovm)]

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).

[3-asn (3-asn)]

First I want https://git.reviewboard.kde.org/r/104642/ to be in before submitting the attached patch.

[Arrigo Marchiori (ardovm)]

Created attachment 72007
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).

[Arrigo Marchiori (ardovm)]

(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.

[B-kde-bugs (b-kde-bugs)]

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:

[Caterpillar (caterpillar86)]

*** Bug 302735 has been marked as a duplicate of this bug. ***

[Caterpillar (caterpillar86)]

it happens also on Fedora KDE 16/17

[Savsem (savsem)]

I use Kate for remote file editing over SFTP, same problem after upgrading to KDE 4.8.4. Password is not recognized.

[DA (adawit)]

(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.

[Rakuco-h (rakuco-h)]

(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?

[DA (adawit)]

(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.

[B-kde-bugs (b-kde-bugs)]

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 <email address hidden> none
debug1: kex: client->server aes128-ctr <email address hidden> 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 <email address hidden>
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"