Version: 4.6 (using KDE 4.6.2) OS: Linux Symptom: Attempting to connect to a host with sftp via a kio slave mechanism (eg dolphin/konqueror) gives the following error: "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." The source of the problem is a new key format being inserted into ~/.ssh/known_hosts by the openssh client, which sftp-kio doesn't recognise. If the host is first connected to via openssh-client, then the new format key is written to known_hosts, and sftp-kio fails with the above error. If the host is first connected to via sft-kio, then the old type of key is written to known_hosts, and dolphin/konqueror successfully connects. Extra system info: KDE 4.6.2 by Debian KDE Maintainers, from their experimental-snapshots repo Debian unstable (up-to-date) 2.6.39 kernel (aptosid) Reproducible: Always Steps to Reproduce: * start with empty ~/.ssh/known_hosts * connect to host via openssh-client, accept the new key * connect to the host with sftp-kio slave eg in dolphin, go to sftp://user@host:port Actual Results: It fails to connect to the host with the error listed above Expected Results: It should connect to the host and allow sftp connection/browsing Some diagnostic discussion at: http://forum.kde.org/viewtopic.php?f=18&t=93475 Further reading pointed to a key format change called ECDSA in openssh 5.7 - I don't know if that is the correct title for this new format, but the timing seems about right. http://mac.softpedia.com/progChangelog/OpenSSH-Changelog-14691.html
*** This bug has been marked as a duplicate of bug 270322 ***
This is not a duplicate of Bug 270322. While both bugs are related to the known_hosts file, that bug is about certain types of host keys not being recognised, while this bug is about hashed host names not being recognised, and it still exists, or at least did in the version in Ubuntu 12.04.
I can confirm this, exactly as described by Bernie. First removing ~/.ssh/known_hosts and then connecting using Dolphin is a possible workaround, but the bug still persists.
Hashed hostnames are supported since a long time. What is the line which doesn't work?
*** This bug has been confirmed by popular vote. ***
Still nobody provides useful information. I think this is a ECDSA key. It should be fixed with libssh 0.6.0rc1.
I cannot confirm if the bug is fixed with libssh 0.6.0rc1, as my so called LTE of Kubuntu 12.04 still sticks with version 0.5.2 :( However, this is a line in my known_hosts (generated with a command line ssh) that doesn't work with konqueror. |1|WeJEBvJkRdhv7k1+Yc8xMIQFwBk=|TvEP38bsRwl495CAq1Uwc2Iw0xY= ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBB9NgJ2Vl78DNBEAxsfLLDF42B9xFsY+yXtDcIYK4TuEmZyU7X4o1A40hEgdVMcIX89wodKa9PK6g03pF7R+tL8= |1|6iOIERS82629o7UlF1AJQBdA9os=|sMXFEZUeSjG0/38eivqsY55yVWI= ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBB9NgJ2Vl78DNBEAxsfLLDF42B9xFsY+yXtDcIYK4TuEmZyU7X4o1A40hEgdVMcIX89wodKa9PK6g03pF7R+tL8= This one (generated by konqueror) does work in command line and in konqueror [xxxxxxxx.com]:9463 ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDIV7Ji2eEeaxrOs6ox8oLkJOvTC8pWe6mLoE8EYRjDBbmggTTfI4KyIjeaiqin3qBf5XAH8UE9ZkHsC5MzTD0IgtJ9cOGhb4j2FueIWsYbxsaH9IIjq7y71dS41zkqcdk63Api4D7AqGGi2MhQXK4Xt6LqqBuQ/8altE0vleqmEapgGyUsNAzryGfTB9ywklB4kSOVHMR0IlcITERPgVlOeu021Nx/oS6BIU/tqa/CcyAIk4thFu0IPah8B0lZGF4Z7hpziu4PiGepPxQNNvxgkXnfERxEYWnk4X4sG0LfiQkjGWIB8NXjfMZKiZneg25N8sy4zraVk91Mp7m5DoRR
Yes, those are ecdsa keys which are not supported by libssh 0.5. You need at least libssh 0.6.0 when it gets released.
Perhaps a regression, but I'm experiencing the same exact bug right now on: Kubuntu 15.04, Dolphin Version 14.12.3 Using KDE Development Platform 4.14.6 With libssh 0.6.3-3ubuntu3 Starting with an empty known_hosts and first doing sftp connection in dolphin adds an entry to known_hosts in an old ssh-rsa format, which is understood by kio and ssh alike. Clearing the known_hosts and connecting with ssh client first adds an ecdsa-sha2-nistp256 host entry which results in an error when later trying to connect to the same host using dolphin: "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."
Take a look at https://bugs.kde.org/show_bug.cgi?id=284867
Confirming this problem on Kubuntu 15.04 Dolphin 15.04.0 KDE Development Platform 4.14.7 dpkg -s libssh-gcrypt-4 | grep Version Version: 0.6.3-3ubuntu3
Workaround is to remove current key and force RSA key usage: ssh-keygen -f "$HOME/.ssh/known_hosts" -R server ssh -o HostKeyAlgorithms=ssh-rsa user@server http://askubuntu.com/a/615916/20275
> [...] > ssh-keygen -f "$HOME/.ssh/known_hosts" -R server > ssh -o HostKeyAlgorithms=ssh-rsa user@server Thank you! Note: If the ssh server uses a port different from 22, then to the last command it must be added: -p port_that_has_to_be_used
(In reply to Andreas Schneider from comment #10) > Take a look at https://bugs.kde.org/show_bug.cgi?id=284867 Bug 284867 seems different from this one, the remote machine's key doesn't change in this one. This also doesn't seem to be a duplicate of Bug 270322. I built libssh from the latest source (v. 0.7.1) and it didn't make a difference. As I explained in the bug report for Ubuntu... https://bugs.launchpad.net/ubuntu/+source/kde-runtime/+bug/1450085/comments/8 ...SSH creates records in ~/.ssh/known_hosts with ECDSA keys -- here's one of mine: === |1|Hwz/WOIxgG55yF711lC97Ty9YH0=|8zGOjdRvU/fcJwZVf3ofvi3qYFc= ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBGjxWXvRxhk9wBmJvMfN389UTpBFBcKIU/mGxQq+pd2lYJ2tYLhh21a1mayv5mfZj4BjfcveuAEEIxPv7XinnnQ= === SFTP however creates records with RSA keys (they begin with "[hostname]:port ssh-rsa") and it doesn't handle ECDSA keys. It would seem SFTP in Kubuntu 15.04 doesn't use libssh.
gcrypt doesn't support ECDSA keys. It is not the fault of libssh that you can't use them. Build libssh with openssl ...
(In reply to Andreas Schneider from comment #15) > gcrypt doesn't support ECDSA keys. It is not the fault of libssh that you > can't use them. Build libssh with openssl ... Built it with OpenSSL, still the same behaviour. Here's what I did & saw: First, I checked what I figured were the relevant cmake options of my previous build, the one apparently w/ gcrypt: GCRYPT_INCLUDE_DIR GCRYPT_INCLUDE_DIR-NOTFOUND GCRYPT_LIBRARY GCRYPT_LIBRARY-NOTFOUND WITH_GCRYPT OFF WITH_SFTP ON OPENSSL_CRYPTO_LIBRARY /usr/lib/x86_64-linux-gnu/libcrypto.so OPENSSL_INCLUDE_DIR /usr/include OPENSSL_SSL_LIBRARY /usr/lib/x86_64-linux-gnu/libssl.so Then, I uninstalled 'libssh-gcrypt-dev' and rebuilt. "make install" then reported the following changes: Install the project... -- Install configuration: "Debug" -- Installing: /usr/lib/pkgconfig/libssh.pc -- Installing: /usr/lib/pkgconfig/libssh_threads.pc -- Installing: /usr/lib/cmake/libssh/libssh-config.cmake -- Installing: /usr/lib/cmake/libssh/libssh-config-version.cmake -- Installing: /usr/include/libssh/callbacks.h -- Installing: /usr/include/libssh/libssh.h -- Installing: /usr/include/libssh/ssh2.h -- Installing: /usr/include/libssh/legacy.h -- Up-to-date: /usr/include/libssh/libsshpp.hpp -- Installing: /usr/include/libssh/sftp.h -- Installing: /usr/include/libssh/server.h -- Installing: /usr/lib/libssh.so.4.4.0 -- Up-to-date: /usr/lib/libssh.so.4 -- Up-to-date: /usr/lib/libssh.so -- Installing: /usr/lib/libssh_threads.so.4.4.0 -- Up-to-date: /usr/lib/libssh_threads.so.4 -- Up-to-date: /usr/lib/libssh_threads.so -- Removed runtime path from "/usr/lib/libssh_threads.so.4.4.0" For this new build I looked for the same cmake options as above: WITH_GCRYPT OFF WITH_SFTP ON OPENSSL_CRYPTO_LIBRARY /usr/lib/x86_64-linux-gnu/libcrypto.so OPENSSL_INCLUDE_DIR /usr/include OPENSSL_SSL_LIBRARY /usr/lib/x86_64-linux-gnu/libssl.so GCRYPT_INCLUDE_DIR & GCRYPT_LIBRARY were missing this time. SFTP created an 'ssh-rsa' record as before and SSH created this record: |1|YQpuZllUwATgLwyUKlmpxl9tEH0=|4rAlT0W5gHsN62IE/I5us4ihdBQ= ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBGjxWXvRxhk9wBmJvMfN389UTpBFBcKIU/mGxQq+pd2lYJ2tYLhh21a1mayv5mfZj4BjfcveuAEEIxPv7XinnnQ=
I still have an issue with kio-sftp if ed25519 type key is *present* in known_hosts file for the host. It does not matter if correct rsa/ecdsa keys are present - if there is ed25519 type key for the host, verification always fails [1] and the hosts' ecdsa key will be appended to known_hosts file every time I click 'connect'. This is a bad behavior regardless of supported key types - the correct behaviour is that not supported key types must be ignored and supported key type must be used. Should I file a new bug report that draws attention to this bad behavior instead of supported key types..? [1] The authenticity of host [...] cannot be established. The ecdsa-sha2-nistp256 key fingerprint is: [...] Are you sure you want to continue connecting? Fedora 37 kf5-kio-core-5.101.0-1.fc37.x86_64 libssh-0.10.4-2.fc37.x86_64
(In reply to Roland Pallai from comment #17) > I still have an issue with kio-sftp if ed25519 type key is *present* in > known_hosts file for the host. It does not matter if correct rsa/ecdsa keys > are present - if there is ed25519 type key for the host, verification always > fails [1] and the hosts' ecdsa key will be appended to known_hosts file > every time I click 'connect'. > > This is a bad behavior regardless of supported key types - the correct > behaviour is that not supported key types must be ignored and supported key > type must be used. > > Should I file a new bug report that draws attention to this bad behavior > instead of supported key types..? > > [1] The authenticity of host [...] cannot be established. The > ecdsa-sha2-nistp256 key fingerprint is: [...] Are you sure you want to > continue connecting? > > Fedora 37 > kf5-kio-core-5.101.0-1.fc37.x86_64 > libssh-0.10.4-2.fc37.x86_64 After some digging I'm sure this is a libssh issue as ssh_session_is_known_server() returns with SSH_SERVER_NOT_KNOWN when ed25519 key is present in known_hosts. There is nothing to fix in kio-sftp..
Please report the bug at libssh upstream: https://gitlab.com/libssh/libssh-mirror/-/issues
(In reply to Andreas Schneider from comment #19) > Please report the bug at libssh upstream: > https://gitlab.com/libssh/libssh-mirror/-/issues As it turned out it was a problem with my known_hosts file: key type `ed25519` was present but correct syntax is `ssh-ed25519` for this type. Sorry for the noise.
(In reply to Roland Pallai from comment #20) > As it turned out it was a problem with my known_hosts file: key type > `ed25519` was present but correct syntax is `ssh-ed25519` for this type. In that case you were lucky, as my `known_hosts` file only has `ssh-ed25519` entries, and I still get this error: ``` An ssh-ed25519 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. ``` Annoyingly `sftp` itself connects just fine using the same URI (with the required additional slash after the hostname). (And I'm feeling stupid; I moved the ed25519 files out of the ~/.ssh directory on both hosts but the corresponding entry keeps getting added right back to my known_hosts file.)