When .ssh/identity private key exists but server rejects it, sftp kio shows "authentication failed" error immediately without asking for password. It happens regardless if correct password was given directly in the URL (sftp://user:password@host:port). After identity file was removed, sftp kio shown password prompt and connected successfully. Debug output: kio_sftp(26412) sftpProtocol::stat: KUrl("sftp://test@172.27.10.1") kio_sftp(26412) sftpProtocol::openConnection: username= "test" , host= "172.27.10.1" , port= 22 kio_sftp(26412) sftpProtocol::sftpOpenConnection: Creating the SSH session and setting options kio_sftp(26412) sftpProtocol::log_callback: [ 1 ] ssh_config_parse_file: Reading configuration data from /home/juro/.ssh/config kio_sftp(26412) sftpProtocol::log_callback: [ 1 ] ssh_config_parse_line: Unsupported option: ForwardX11, line: 4 kio_sftp(26412) sftpProtocol::log_callback: [ 1 ] ssh_config_parse_line: Unsupported option: ForwardX11, line: 10 kio_sftp(26412) sftpProtocol::log_callback: [ 1 ] ssh_config_parse_line: Unsupported option: ForwardX11, line: 17 kio_sftp(26412) sftpProtocol::log_callback: [ 1 ] ssh_config_parse_line: Unsupported option: ControlMaster, line: 18 kio_sftp(26412) sftpProtocol::log_callback: [ 1 ] ssh_config_parse_line: Unsupported option: ForwardX11, line: 26 kio_sftp(26412) sftpProtocol::log_callback: [ 1 ] ssh_config_parse_line: Unsupported option: ForwardX11, line: 33 kio_sftp(26412) sftpProtocol::log_callback: [ 1 ] ssh_config_parse_line: Unsupported option: ForwardX11, line: 39 kio_sftp(26412) sftpProtocol::log_callback: [ 1 ] ssh_config_parse_line: Unsupported option: ServerAliveInterval, line: 41 kio_sftp(26412) sftpProtocol::log_callback: [ 1 ] ssh_config_parse_line: Unsupported option: LocalForward, line: 42 kio_sftp(26412) sftpProtocol::log_callback: [ 1 ] ssh_config_parse_line: Unsupported option: RemoteForward, line: 43 kio_sftp(26412) sftpProtocol::log_callback: [ 1 ] ssh_config_parse_line: Unsupported option: ForwardX11, line: 48 kio_sftp(26412) sftpProtocol::log_callback: [ 1 ] ssh_config_parse_line: Unsupported option: ForwardX11, line: 57 kio_sftp(26412) sftpProtocol::log_callback: [ 1 ] ssh_config_parse_line: Unsupported option: ForwardX11, line: 62 kio_sftp(26412) sftpProtocol::log_callback: [ 1 ] ssh_config_parse_line: Unsupported option: ForwardX11, line: 69 kio_sftp(26412) sftpProtocol::log_callback: [ 1 ] ssh_config_parse_line: Unsupported option: ForwardX11, line: 76 kio_sftp(26412) sftpProtocol::log_callback: [ 1 ] ssh_config_parse_line: Unsupported option: ForwardX11, line: 83 kio_sftp(26412) sftpProtocol::log_callback: [ 1 ] ssh_config_parse_line: Unsupported option: ControlMaster, line: 87 kio_sftp(26412) sftpProtocol::log_callback: [ 1 ] ssh_config_parse_line: Unsupported option: ControlPath, line: 88 kio_sftp(26412) sftpProtocol::log_callback: [ 1 ] ssh_config_parse_file: Reading configuration data from /etc/ssh/ssh_config kio_sftp(26412) sftpProtocol::log_callback: [ 1 ] ssh_config_parse_line: Unsupported option: SendEnv, line: 51 kio_sftp(26412) sftpProtocol::sftpOpenConnection: Trying to connect to the SSH server kio_sftp(26412) sftpProtocol::log_callback: [ 1 ] ssh_connect: libssh 0.6.3 (c) 2003-2014 Aris Adamantiadis, Andreas Schneider, and libssh contributors. Distributed under the LGPL, please refer to COPYING file for information about your rights, using threading threads_noop kio_sftp(26412) sftpProtocol::log_callback: [ 1 ] socket_callback_connected: Socket connection callback: 1 (0) kio_sftp(26412) sftpProtocol::log_callback: [ 1 ] ssh_client_connection_callback: SSH server banner: SSH-2.0-OpenSSH_6.6p1-hpn14v4 kio_sftp(26412) sftpProtocol::log_callback: [ 1 ] ssh_analyze_banner: Analyzing banner: SSH-2.0-OpenSSH_6.6p1-hpn14v4 kio_sftp(26412) sftpProtocol::log_callback: [ 1 ] ssh_analyze_banner: We are talking to an OpenSSH client version: 6.6 (60600) kio_sftp(26412) sftpProtocol::openConnection: Getting the SSH server hash kio_sftp(26412) sftpProtocol::openConnection: Checking if the SSH server is known kio_sftp(26412) sftpProtocol::openConnection: Trying to authenticate with the server kio_sftp(26412) sftpProtocol::log_callback: [ 1 ] ssh_packet_userauth_failure: Access denied. Authentication that can continue: publickey,keyboard-interactive kio_sftp(26412) sftpProtocol::openConnection: Trying to authenticate with public key kio_sftp(26412) sftpProtocol::log_callback: [ 1 ] ssh_agent_get_ident_count: Answer type: 12, expected answer: 12 kio_sftp(26412) sftpProtocol::log_callback: [ 1 ] ssh_packet_userauth_failure: Access denied. Authentication that can continue: publickey,keyboard-interactive kio_sftp(26412) sftpProtocol::log_callback: [ 1 ] ssh_userauth_publickey_auto: Failed to import public key: /home/juro/.ssh/identity.pub kio_sftp(26412) sftpProtocol::openConnection: Public key authentication failed: "Failed to import public key: /home/juro/.ssh/identity.pub" kio_sftp(26412) sftpProtocol::closeConnection: Reproducible: Always Steps to Reproduce: 1. Generate SSH keypair into default location (~/.ssh/identity) but do not upload it to server 2. Try to open sftp://user@any_existing_server Actual Results: "authentication failed" error Expected Results: Password prompt, or it should use password supplied in URL.
And what exactly is the bug here? kio_sftp is not going to prematurely prompt you for password before it can determine that it needs to prompt you for a password. In order to do that it needs to communicate with the server, but the server rejected the request. In fact the request is rejected right at the place where it was attempting to determine what mode of authentication to use. Sorry but this is correct behavoir.
Please? 1. You explicitly indicate that password should be used by adding correct password in the URL 2. sftp stubbornly ignores it because it latched on .ssh/identity 3. you'll get "authentication failed" How this is not a bug? If you insist it should be so, then sftp should properly inform user that his attempts at using password are futile.
(In reply to Juraj Variny from comment #2) > Please? > > 1. You explicitly indicate that password should be used by adding correct > password in the URL > 2. sftp stubbornly ignores it because it latched on .ssh/identity > 3. you'll get "authentication failed" > > How this is not a bug? > > If you insist it should be so, then sftp should properly inform user that > his attempts at using password are futile. Oh I get it now. My mistake. I completely misunderstood your original report though I read it a couple of times. What you are saying is that if one of the authentication method fails, publickey authentication, then it should try another one, keyboard-interactive authentication, and not fail because the first mode failed, right? Does the command line sftp allow you to do this? BTW, specifying the password in the URL does not mean you want to use one authentication method over the other. IOW, that will not override something else that is specified in your ssh config file. None of the protocols in KDE work that way and in fact people are discouraged from specifying passwords in URL for a very obvious reason. It is supported because the URL specification supports it.
I've been running into this problem as well, and the solution is to move away ~/.ssh/identity and ~/.ssh/identity.pub . It's annoying.
Is this still reproducible with libssh 0.9+ and kio-extras 19.12+? If so, which exact versions.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!