When I connect to my "OpenSSH_8.2p1 Ubuntu-4ubuntu0.4" server alternating using

sftp -v -o HostKeyAlgorithms=ecdsa-sha2-nistp256 test-user@localhost


sftp -v -o HostKeyAlgorithms=rsa-sha2-256 test-user@localhost

I always get when switching from one algorithm to the other the following warning:


Is this the correct behavior that it is not possible to use ECDSA and RSA Host-Key-Algorithms in parallel, or is this a bug?

2 Answers 2


SSH (ssh and other programs that run it, such as scp and sftp) stores its keys in ~/.ssh/known_hosts by default. It identifies hosts by their keys.

In this case, you presumably have one of those keys (ECDSA or RSA) stored in that file and your SSH configuration (~/.ssh/config or else the system-wide copy in /etc/ssh/ssh_config or a similar location) is using StrictHostKeyChecking (see its entry in ssh_config(5)).

When you connect to the other one, run it like this (correct the key algorithm if I guessed it wrong):

sftp -v -o HostKeyAlgorithms=rsa-sha2-256 -o StrictHostKeyChecking=ask test-user@localhost

Ask is the default for this setting. With it enabled, you should then be prompted to save the second key. You won't need it in subsequent connections since both keys will be saved.

  • Hi Adam, no this is not working "-o StrictHostKeyChecking=ask" does not make any difference. Did you test it yourself? My local sshd and sftp is "OpenSSH_8.2p1 Ubuntu-4ubuntu0.4, OpenSSL 1.1.1f".
    – becke-ch
    Jul 14, 2022 at 21:36
  • Could you comment on what your ~/.ssh/known_hosts looks like? Also, what are you running as the client (OS, sftp, OpenSSH versions)?
    – Adam Katz
    Jul 14, 2022 at 21:39
  • OS: Ubuntu 20.04.4 LTS; SSH/SFTP/SSHD: OpenSSH_8.2p1 Ubuntu-4ubuntu0.4, OpenSSL 1.1.1f 31 Mar 2020; because the known_hosts file was quite long I just emptied it but the error/bug still occurrs and "-o StrictHostKeyChecking=ask" seems not working/fixing. I either get "Offending ECDSA key in ... known_hosts ..." or "Offending RSA key in ...". It seems an OpenSSH bug that these public key algorithms cannot coexist. And Strict Host Checking actually should not prevent that different algorithms can be used in parallel. Could you get it working?
    – becke-ch
    Jul 16, 2022 at 13:21
  • You're right, the error from StrictHostKeyChecking=yes is rather explicit ("No ECDSA host key is known for localhost and you have requested strict checking.") If you cleared your ~/.ssh/known_hosts, then perhaps the issue is your GlobalKnownHostsFile, e.g. /etc/ssh/ssh_known_hosts, but that's not automatically populated.
    – Adam Katz
    Jul 18, 2022 at 14:47

This is normal behavior. An SSH server is identified by its public key. An SSH server can only have multiple public keys if they're keys of different types (RSA, ECDSA, EdDSA, …). Normally, a given client machine always uses the same key type when talking to a given server (based on the client and server's support list and preferences), so the client always sees the same server key.

You're simulating the use of different SSH clients on the same machine, one that only supports RSA and one that only supports ECDSA. These clients see different server identities. But they share the same known_hosts file that stores the client's memory of server identities. Let's say you use the RSA client first. It sees that localhost has a certain RSA public key, asks you to check whether this is correct, and when you say “yes”, it records the key in ~/.ssh/known_hosts. Then, when you run the ECDSA client, it receives the server's ECDSA public key, which does not match what is stored in ~/.ssh/known_hosts. This indicates that something is deeply wrong: possibly an attack, possibly some misconfiguration, possibly that the server has been legitimately reinstalled. The SSH client has no way to know which one it is, so it lets you know and aborts the connection attempt.

If you have different SSH client software on the same machine that don't support the same public key algorithms, you need to make them use different known_hosts files. OpenSSH does not support having multiple public keys corresponding to the same server, which makes sense since it would be extremely rarely useful but would be very easy to accidentally misuse.

  • Thx for the reply. I still think the ssh client should just give a warning but accept the user decision to support different algos for the same server in parallel. Maybe you can add the following workaround/solution to your reply: "When forcing the ssh client not to use the default public key algorithm then you should as well force the client not to use the default known_hosts file e.g.: sftp -v -o HostKeyAlgorithms=ecdsa-sha2-nistp256 test--s0-v1@localhost" sftp -v -o HostKeyAlgorithms=ecdsa-sha2-nistp256 -o UserKnownHostsFile=~/.ssh/known_hosts_ecdsa test--s0-v1@localhost`
    – becke-ch
    Dec 14, 2022 at 12:17
  • @becke-ch It's not just a matter of “accept the user decision”. The client program has no way to know that the two keys are for the same machine. What you're doing is very unusual (and I don't understand why you're doing it, you seem to be making your life more complicated for no benefit). Dec 14, 2022 at 12:23
  • (I'm using the OpenSSH SFTP Server Client for automated integration testing of my Android Java based SFTP Server implementation and in this context testing the different public key algorithms)
    – becke-ch
    Dec 14, 2022 at 19:50
  • @becke-ch Ok, but why are you sharing known_hosts between tests? It looks like your test environment is not properly isolated. Dec 14, 2022 at 21:49
  • I did not invest too much time in my test code but thx for the hint. I've put in on the agenda for next release/cleanup to implement separate known_hosts files for the different tests.
    – becke-ch
    Dec 15, 2022 at 16:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .