18

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.

1
  • 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 May 4 '18 at 23:35
17

By removing the ECDSA algorithms from the HostKeyAlgorithms configuration variable.

ssh -o HostKeyAlgorithms=ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-dss-cert-v00@openssh.com,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 ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-dss-cert-v00@openssh.com,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 ssh-rsa-cert-v01@openssh.com,ssh-rsa instead. – cowlinator Feb 19 '19 at 22:23
6

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
  • 3
    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? – enthusiasticgeek Dec 8 '14 at 23:02
  • @RobertSiemer only the original question poster can change the accepted answer. I am unable to do so. – enthusiasticgeek Feb 16 '16 at 4:15
  • 1
    H2ONaCl: please change your accepted answer. This one does not do what you asked for. @enthusiasticgeek sorry, mixup. – Robert Siemer Feb 16 '16 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 Jun 27 '18 at 9:40
6

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

ssh -o HostKeyAlgorithms=ssh-rsa -o FingerprintHash=md5 user@example.com
2
  • 1
    This gives "Bad configuration option: fingerprinthash" on my system (OpenSSH_6.6.1p1). – Soren Bjornstad Nov 5 '16 at 14:46
  • 2
    @SorenBjornstad, the FingerprintHash option is unnecessary, just leave that whole part off. – Lucas Jan 6 '17 at 21:54
2

I just added this line

HostKeyAlgorithms ssh-rsa

to

/etc/ssh/sshd_conf

and it's working fine in this version.

OpenSSH_7.7p2 ubuntu-4ubuntu2.2
1

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:

ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa

You should end up with:

ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,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 ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa

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

Host somehost
    HostKeyAlgorithms ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,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.

-1

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.

1
  • 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 Oct 26 '18 at 20:30
-5

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
  • 1
    You realize that the question was not about the client-side key but about the server key? – 0xC0000022L Jul 29 '15 at 22:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.