Upon the first time accessing a server, how can I force SSH to give me the RSA key and automatically store it if the user approves?

Presently it is offering me the ECDSA key. Because I already know the RSA key, I would prefer to see the RSA key presented at this point.

I have tried:

ssh -o RSAAuthentication=yes user@server

Unfortunately this gives me an ECDSA key and the Are you sure you want to continue connecting (yes/no)? message.

  • I have a similar situation. Server A. Client B. On B: ssh A will first ask you for the key. On Cleint C: ssh A will first ask you for passwrd, after an failed the attempt to for Client C to use ECDSA key, I saw this on the log of A. If I preload rsa key on C, then ssh A will connect happily. How do I prevent C from use ECDSA key as the first attempt?
    – Kemin Zhou
    Commented May 4, 2018 at 23:35

7 Answers 7


By removing the ECDSA algorithms from the HostKeyAlgorithms configuration variable.

ssh -o [email protected],[email protected],[email protected],[email protected],ssh-rsa,ssh-dss user@server

I've simply removed all the ECDSA algorithms from the default list.

You can, of course, put that in your .ssh/config for that machine:

Host: server
    HostKeyAlgorithms [email protected],[email protected],[email protected],[email protected],ssh-rsa,ssh-dss
  • 1
    For OpenSSL, 1) there is no colon after host, and 2) the default list seems to have changed since you posted this. Try HostKeyAlgorithms [email protected],ssh-rsa instead.
    – cowlinator
    Commented Feb 19, 2019 at 22:23

Yes, OK switch to ECDSA soon, but in the meantime try this:

ssh -o HostKeyAlgorithms=ssh-rsa -o FingerprintHash=md5 [email protected]
  • 1
    This gives "Bad configuration option: fingerprinthash" on my system (OpenSSH_6.6.1p1). Commented Nov 5, 2016 at 14:46
  • 2
    @SorenBjornstad, the FingerprintHash option is unnecessary, just leave that whole part off.
    – Lucas
    Commented Jan 6, 2017 at 21:54

Don't use RSA since ECDSA is the new default.

On the server do this: ssh-keygen -l -f /etc/ssh/ssh_host_ecdsa_key.pub and record that number.

On the client you can SSH to the host and if and when you see that same number, you can answer the prompt Are you sure you want to continue connecting (yes/no)? affirmatively. Then the ECDSA key will get recorded on the client for future use.

  • 4
    yeah but how about if I have an old application that needs RSA to maintain compatibility until there is a business decision to update to ecdsa? Commented Dec 8, 2014 at 23:02
  • @RobertSiemer only the original question poster can change the accepted answer. I am unable to do so. Commented Feb 16, 2016 at 4:15
  • 1
    H2ONaCl: please change your accepted answer. This one does not do what you asked for. @enthusiasticgeek sorry, mixup. Commented Feb 16, 2016 at 15:34
  • Default (appeal to authority) and new (appeal to novelty) does not necessarily mean better. RSA is still considered strong... just up the bits to 4096 if you want more strength (2048 might be obsolete soon). And if you want a good EC algo, use ed25519. ECDSA sucks because it uses weak NIST curves which are possibly even backdoored; this has been a well known problem for a while. So for legacy support, enable RSA, and for an ideal algo, use ed25519...always disable DSA which is long obsolete (a major reason is fixed size 1024 bit key) and also disable ECDSA. Try ssh-audit for more.
    – Peter
    Commented Jun 27, 2018 at 9:40

I just added this line

HostKeyAlgorithms ssh-rsa



and it's working fine in this version.

OpenSSH_7.7p2 ubuntu-4ubuntu2.2

Just to improve tumbleweed's answer which has a dead link in it for finding the old list of algorithms.

First decide on a list of algorithms. To find the old list, use ssh -vv:

ssh -vv somehost

And look for the 2 lines like "host key algorithms: ..." where the first appears to be the server's offer, and the 2nd is the client's. Or to pick out those 2 lines automatically, try this (and to exit hit ctrl+d):

ssh -vv somehost 2>&1 | grep "host key algorithms:"

Now filter it down... you should remove all the dss/dsa ones since they are long obsolete, and you also wanted to remove ecdsa (as do I), so for example if you had:

[email protected],[email protected],[email protected],[email protected],[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa

You should end up with:

[email protected],[email protected],ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa

Now edit your config. For your own config:

vim ~/.ssh/config

For the system wide config:

sudo vim /etc/ssh/ssh_config

Add a new line, either globally:

HostKeyAlgorithms [email protected],[email protected],ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa

or for a specific host (not ideal for server wide config):

Host somehost
    HostKeyAlgorithms [email protected],[email protected],ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa

Instead of the list I entered, paste the list you derived from the ssh -vv output, not incluing the "host key algorithms:" part.


some points are confusing as to is it possible to remove key algorithms from existing defaults - Highest level keys are New RSA-sha2/256/512 and ed25519 keys for best security using ssh-keygen -t ras -a -b 4096 -a 113 to gen. Legacy support is apparently reading ssh news that ssh1 will be totally gone - its 45bit and 96 bit max - dsa keys also depreciated also be eliminated. Its fixed on 128/1024 bit max found hackable. (poss NSA did that and lame/excuse as debug code left in- highly doubt that naming it heartbleed) so all high cost paying secure RSA key structures have to be reworked to support and keep higher standards going forward. set what keys you wish to use as described in /etc/ssh/sshd_config try doing 2 key auth 3 key works too ie: sshd_config "AuthenticationMethods publickey,publickey,publickey"- make sure ssh -Q kex listings match both A and B servers or desktops as example poss do a diff on their output - and make sure same key exhng algorithms match. ecdsa keys newer in production are also kina weak sugg not to use. or get - keyexchange refused partial access secure msg. Lots of good infoz just patient to search it.

  • 3
    Could you try to break up this wall of text so it's easier to follow? Please make use of the formatting guide and format code and text file contents as code, and if it will make things clearer, put them on their own lines. I would happily edit your answer myself if I could follow it, but I can't.
    – Zanna
    Commented Oct 26, 2018 at 20:30

Or, if you insist on having the RSA key approach, you can type ssh-keygen -t rsa on the server that you intend to SSH to.

That should generate RSA public and private keys under '~/.ssh/id_rsa'. Now all you need to do is to copy the public key under $HOME/.ssh/authorized_keys of all those machines from which you intend to ssh to the machine on which you generated your RSA keys.

And then sit back and relax!

  • 1
    You realize that the question was not about the client-side key but about the server key? Commented Jul 29, 2015 at 22:47

You must log in to answer this question.

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