Version: 4.7 (using KDE 4.7.2) OS: Linux If an SSH host key on a remote system changes, kio_sftp will die, offering no way to resolve the issue. Certainly, I wouldn't expect it to ignore the host key change, since that's a potential security problem. But, it should be able to notify the user, and allow them to choose whether or not to ignore the change, and update the known_hosts file appropriately if the user does choose to ignore it. Reproducible: Always Steps to Reproduce: 1. Connect to a remote system with SSH and/or browse the system using the sftp:// support in Dolphin or Konqueror. 2. Re-install the OS on the remote system (this is a common scenario). 3. Try to connect to the system again using the sftp:// support in Dolphin or Konqueror. Actual Results: It displays the following message: The requested operation could not be completed Connection to Server Closed Unexpectedly Details of the Request: URL: sftp://root@172.26.21.45/ Protocol: sftp Date and Time: Monday, October 24, 2011 09:26 AM Additional Information: The host key for the server 172.26.21.45 has changed. This could either mean that DNS SPOOFING is happening or the IP address for the host and its host key have changed at the same time. The fingerprint for the key sent by the remote host is: 47:b5:32:8c:4c:20:1c:7a:53:bc:b6:0a:ee:12:94:f5 Please contact your system administrator. Description: Although a connection was established to 172.26.21.45, the connection was closed at an unexpected point in the communication. Possible Causes: There may have been a problem with your network connection. There may have been a problem at some point along the network path between the server and this computer. A protocol error may have occurred, causing the server to close the connection as a response to the error. Possible Solutions: Try again, either now or at a later time. Contact the administrator of the server for further assistance. Contact your appropriate computer support system, whether the system administrator, or technical support group for further assistance. Expected Results: It should notify the user of a potential security problem, but offer to ignore the issue and connect anyway. I would consider this a bug and not a feature request, since the user should NOT have to go mucking around inside a known_hosts file manually to work-around this problem. In my opinion, this is also a bug in the OpenSSH client, since it also has the same basic activity, but that's their problem to deal with.
This bug is still present in KDE 4.8.2. In Dolphin, this is the error message I get: "Connection to host The host key for this server was not found, but another type of key exists. An attacker might change the default server key to confuse your client into thinking the key does not exist. Please contact your system administrator. is broken." I can use ssh and sftp on the command line correctly, so it has nothing to do with ~/.ssh/known_hosts, which I had updated with the new key already. Is there a KDE-only known_hosts file somewhere which I can change to work around this bug for the time being? Also, I would consider this a severe bug in the sftp kio since, as the original poster said, changing the server ssh key is common and sftp in KDE becomes useless once that happens.
The message "Connection to host The host key for this server was not found, but another type of key exists. An attacker might change the default server key to confuse ..." looks correct. kio_sftp uses the same ~/.ssh/known_hosts as the ssh binary if you don't have defined something else in the config file.
I've tried to reproduce it here with KDE 4.8.2 and the message Connection to host The host key for this server was not found, but another type of key exists. An attacker might change the default server key to confuse your client into thinking the key does not exist. Please contact your system administrator. is correctly displayed. asn@magrathea:~> ssh localhost @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. The fingerprint for the ECDSA key sent by the remote host is 09:a8:19:7a:ac:e8:a6:b2:ac:a1:a9:99:7f:d2:cf:48. Please contact your system administrator.
As I said, ssh on the terminal works and there is no warning at all, but the sftp: protocol via Dolphin gives the message I posted earlier. This doesn't make much sense if both use the same known_hosts file. Is there a way for me to debug this problem to try to figure out what's going on?
Enable debugging: http://techbase.kde.org/Development/Tutorials/Debugging/Debugging_IOSlaves/Debugging_kio_sftp KIO_SFTP_LOG_VERBOSITY=1 kdeinit4 try 1 and 2 as values.
This is the data I get: kio_sftp(10072) sftpProtocol::stat: KUrl("sftp://xxx") kio_sftp(10072) sftpProtocol::openConnection: username= "" , host= "xxx" , port= 0 kio_sftp(10072) sftpProtocol::openConnection: checking cache: info.username = "" , info.url = "sftp://xxx" kio_sftp(10072) sftpProtocol::openConnection: Creating the SSH session and setting options [1] Reading configuration data from /home/eike/.ssh/config [1] Unsupported option: ServerAliveInterval, line: 29 [1] Reading configuration data from /etc/ssh/ssh_config [1] Unsupported option: ForwardX11Trusted, line: 32 [1] Unsupported option: SendEnv, line: 67 [1] Unsupported option: SendEnv, line: 68 [1] Unsupported option: SendEnv, line: 69 [1] Unsupported option: VisualHostKey, line: 73 [1] Unsupported option: HashKnownHosts, line: 77 kio_sftp(10072) sftpProtocol::openConnection: Trying to connect to the SSH server kio_sftp(10072) sftpProtocol::log_callback: [ 1 ] libssh 0.5.1 (c) 2003-2010 Aris Adamantiadis (aris@0xbadc0de.be) Distributed under the LGPL, please refer to COPYING file for information about your rights, using threading threads_noop kio_sftp(10072) sftpProtocol::log_callback: [ 1 ] Socket connection callback: 1 (0) kfilemetadatareader(10073)/nepomuk (library) {anonymous}::GlobalModelContainer::init: Connecting to local socket "/tmp/ksocket-eike/nepomuk-socket" kio_sftp(10072) sftpProtocol::log_callback: [ 1 ] SSH server banner: SSH-2.0-OpenSSH_5.8 kio_sftp(10072) sftpProtocol::log_callback: [ 1 ] Analyzing banner: SSH-2.0-OpenSSH_5.8 kio_sftp(10072) sftpProtocol::log_callback: [ 1 ] We are talking to an OpenSSH client version: 5.8 (50800) kio_sftp(10072) sftpProtocol::openConnection: Getting the SSH server hash kio_sftp(10072) sftpProtocol::openConnection: Checking if the SSH server is known kio_sftp(10072) sftpProtocol::closeConnection: kio_sftp(10072) sftpProtocol::sftpConnect: connected ? false username: old= "" new= "" This is a amd64 openSUSE 12.1 system running KDE SC 4.8.5
The problem here is not that the host key on a remote system changes (for which the user gets notified with a brief explanation when the sftp:// kio-slave works properly [ssh_key_changed_on_host.jpeg]), but the sftp:// kioslave not supporting ecdsa (which results in the error message noted above in dolphin [ssh_key_is_ecdsa_on_host.jpeg]). From the OpenSSH 5.7 release notes: ECDH in a 256 bit curve field is the preferred key agreement algorithm when both the client and server support it. ECDSA host keys are preferred when learning a host's keys for the first time, or can be learned using ssh-keyscan(1). This alone isn't a problem, when the connection already worked before, since the entries in the .ssh/known_hosts file are still ssh-rsa or ssh-dsa for the existing servers. But as soon as you try to connect to a new server or if the keys change then the ssh authentification defaults to the highest key agreement algorithm which is ecdsa-sha2-nistp256 these days. And this currently fails with the sftp:// kio slave. A really arkward workaround on the server-side is to delete the ssh_host_ecdsa_key{,.pub} keys on the server, restart sshd and be sure to check for the deamon startup scripts to NOT generate ecdsa again keys on startup. Workaround for the client-side is to use fish:// in the meanwhile which works (probably different?). But as ecdsa is the (new) standard in OpenSSH this should really get fixed for the sftp:// kioslave.
Created attachment 73180 [details] ssh_key_changed_on_host.jpeg
Created attachment 73181 [details] ssh_key_is_ecdsa_on_host.jpeg
I believe we have two different issues being discussed here. The one that I originally filed the bug for is VERY easy to reproduce: 1. Connect to an SFTP share on some system using Dolphin/Konqueror. 2. On the remote system, remove the ssh_host_* key files out of /etc/ssh. 3. Generate new host keys on the remote system using ssh-keygen. 4. Restart SSH on the remote system. 5. Attempt to connect to the same SFTP with Dolphin/Konqueror. I'm attaching a screenshot of the error that I receive each time. In my testing, the key types were rsa in all cases.
Created attachment 73182 [details] Error message as described in the original bug report.
I get the error message from ssh_key_is_ecdsa_on_host.jpeg. And fish:// works for me too.
Forgot to mention that I upgraded to 4.9.0 and the behavior is still the same.
I've implemented ecdsa support in libssh. When I'm back from vacation I try to relase a new version of libssh with ECDSA support soon.
*** Bug 294818 has been marked as a duplicate of this bug. ***
Looks to me like the host key checking algorithm ignores the TCP port. This is fatal for anybody who wants to use an ssh tunneling. In such case various ports of the same IP address leads to different server. This means, that if the host checking algorithm ignores the port, you cannot connect to more than one port. If you use the connection to the "tunneling" server itself, you cannot use any of tunnels established on this server. Note, that command-line ssh and scp allows it.
I experience exactly the case Petr J. Borsky is describing, (Also KDE 4.8.4, debian wheezy)
Petr: Please open a bug at http://red.libssh.org
Andreas: Why do you think this is a libssh bug? I'm not convinced so, because command-line tools doesn't show this problem.
Which command line tool?
+1 for this. "ssh" does notify the user when host key changed. Dolphin/kio-fish should too. See also bug 272811.
Andreas: sorry for delay. Command line tools I've already mentioned: ssh, scp... I'll try to give an example. There is a server machine with single IP address - listening on three ports - 22, 2201, 2202. server-machine:22 -> internal ssh server directly on server-machine server-machine:2201 -> tunnel to ssh server on another-machine-01 server-machine:2202 -> tunnel to ssh server on another-machine-02 Command "ssh server-machine" connects to server-machine. Command "ssh -p 2201 server-machine" connects to another-machine-01 (via tunnel). Command "ssh -p 2202 server-machine" connects to another-machine-02 (via tunnel). No of that commands makes any complain about anything. Address line "sftp://server-machine" in Dolphin works - dolphin connects to server-machine. Address line "sftp://server-machine:2201" in Dolphin fails. Address line "sftp://server-machine:2202" in Dolphin fails. The fail is accompanied with this error message: " The host key for the server stal189 has changed. This could either mean that DNS SPOOFING is happening or the IP address for the host and its host key have changed at the same time. The fingerprint for the key sent by the remote host is: some:hexadecimal:fingerprint Please contact your system administrator. " Note, that the fingerprint is the same in both situations. (tested on KDE version 4.14.2) Are you still convinced this is a libssh issue?
Fresh update: seems to me it still have something to do with a record type in known_hosts file (as Timo Gurr writes). When the record is written by kio, the type of record is RSA and kio works as expected - i.e. connects to any port of given server. When the record is written by command-line tool (ssh, scp, sftp), the type of record is ECDSA and kio is able to connect only to one port of given server. So there is a workaround: remove all records of this server from known_hosts file (with ssh-keygen -R [server-name]:port). Restart the application which uses kio and connect step by step to all ports of your server via kio sftp. Up to my experiments it is important to remove ALL records concerning the server, which could be a pain. So it would be better to find and fix the bug in kio :-)
This sounds like you do not have a libssh library with ECDSA support on your system. Upgrade to the latest libssh version and make sure that libssh is build with ECDSA support.
It's a news for me, that OpenSSH command tools (ssh, scp...) and libssh are two completely different implementations of SSH; to be honest a bad news, but it explains a lot. Andreas, could you please be more specific about libssh version? Seems to me, that ECDSA support has be implemented in 0.6.0; I have 0.6.3, which is the last available for my system (Debian). There are one more version released (not yet adopted by Debian) - 0.6.4, where is mentioned some ECDSA improvement as well. So which version should solve this misbehavior in kio_sftp?
"Give the programmer some credit for basic intelligence: if the program really didn't work at all, they would probably have noticed. Since they haven't noticed, it must be working for them. Therefore, either you are doing something differently from them, or your environment is different from theirs. They need information; providing this information is the purpose of a bug report. More information is almost always better than less." http://www.chiark.greenend.org.uk/~sgtatham/bugs It should work with libssh 0.6.3 then. If it doesn't for you I need more information. Which SSH versions and implementations are involved. Is the libssh library built with ECC support? Some distributions disabled ECC in openssl cause of possible IP issues. Post line in the known_hosts file libssh can't deal with. Do you use the default port or a different one, etc.
*** Bug 346922 has been marked as a duplicate of this bug. ***
Here's a workaround I wrote up for this, which is a bit more secure than the ones above, because you don't have to throw out your known_hosts file entries: ssh to the server in question on the remote server, run: $ ssh-keyscan [ -p<port_number> ] -t rsa localhost This will return something like this: # localhost SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2 localhost ssh-rsa AAAAagyag9bhghgahaGAGGGASgdgs9D... Copy that long second line beginning with 'localhost' into your ~/.ssh/known_hosts file, and replace 'localhost' with the server name you're using in konqueror. Try konqueror again. If you're using a nonstandard ssh port and Konqueror still doesn't work, edit your known_hosts file again and change the hostname to the IP address of the server and the port number, in this format: [192.168.6.1]:2202 If you now get "Additional Information: Authentication failed." because you use ECDSA keys to authenticate, generate an RSA identity key and add it to authorized_keys on the remote server. If necessary, modify .ssh/config for the host to tell ssh to use that key. If you can connect but still encounter random hanging / "authentication failed" only intermittently, try adding your username and the port number to the sftp URL, and starting konqueror with: KDE_FORK_SLAVES=true konqueror
Is this still reproducible with the 19.12 release? If so which libssh version is used? Which distribution? What's the SSH server? What version does it have? Ideally someone should write an actual guide on how to reproduce this on distribution x or environment y.
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!