Cisco 9200 Switches Moving SSH from RSA Keys to ECDSA Keys

[OSUOPT]

Due to the recent vulnerability https://terrapin-attack.com/ that is a MITM attack against weaker SSH algorithms. We are wanting to move our SSH authentication and algorithms to non affected algorithms including newer security algorithms such as ECDSA. I am attempting to figure out what I need to do get SSH shifted over to ECDSA. I am running the following commands

ip ssh version 2
ip ssh time-out 120
ip ssh authentication-retries 3
ip ssh server algorithm publickey ecdsa-sha2-nistp256 ecdsa-sha2-nistp384 ecdsa-sha2-nistp521
ip ssh server algorithm hostkey x509v3-ssh-rsa rsa-sha2-512 rsa-sha2-256
ip ssh server algorithm encryption aes256-gcm aes256-ctr
ip ssh server algorithm mac hmac-sha2-256 hmac-sha2-512
ip ssh server algorithm kex ecdh-sha2-nistp256 ecdh-sha2-nistp384 ecdh-sha2-nistp521
crypto key generate ec keysize 256
To limit down how you can authenticate via SSH but the previously used RSA key is still present when showing the ssh information (show ip ssh) and please note that this is before I run any of these commands on a switch.

Hostname>show ip ssh
SSH Enabled - version 2.0
Authentication methods:publickey,keyboard-interactive,password
Authentication Publickey Algorithms:x509v3-ssh-rsa,ssh-rsa,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,x509v3-ecdsa-sha2-nistp256,x509v3-ecdsa-sha2-nistp384,x509
Hostkey Algorithms:x509v3-ssh-rsa,rsa-sha2-512,rsa-sha2-256,ssh-rsa
Encryption Algorithms:chacha20-poly1305@openssh.com,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-gcm,aes256-gcm,aes128-ctr,aes192-ctr,aes256-ctr
MAC Algorithms:hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
KEX Algorithms:curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group14-sha1
Authentication timeout: 120 secs; Authentication retries: 3
Minimum expected Diffie Hellman key size : 2048 bits
IOS Keys in SECSH format(ssh-rsa, base64 encoded): TP-self-signed
Modulus Size : 2048 bits
ssh-rsa ****

After I run these commands what additional commands do I need to run to force SSH to use the newly generated ecdsa keys instead and is there anything else I am missing?

The only information I found that I am unsure if it will even work is to completely remove the RSA key but dont know if it will default to ECDSA afterward.

Remove a single RSA file

crypto key zeroize rsa label XXXX (Name of the current rsa key)

Remove all RSA files

crypto key zeroize rsa

[M02@rt37]

Hello @OSUOPT 

From my point of view, with Cisco IOS devices, the ssh server generally uses the first available key for authentication. If you want to prioritize ECDSA over RSA, you can generate ECDSA keys and then remove the RSA keys.

Remove all RSA keys:

crypto key zeroize rsa

By removing the RSA keys, the server may default to the first available ECDSA key for authentication.

N.B: if you are in a production context, ensure you have alternative means to access the device if needed.

[OSUOPT]

Hello, I used that command to clear out the RSA keys but it was still defaulting to rsa for ssh and not ecdsa when I use the "show ip ssh" command. Any ideas what else I need to do to force it to switch over to ecdsa?

[M02@rt37]

@OSUOPT 

You do 

device(config)#crypto key zeroize rsa

After that you create the ECDSA ? 

Sh ip SSH ?

[OSUOPT]

Yes I ran that command

device(config)#crypto key zeroize rsa

 Then afterward ran the command to show that the RSA keys were deleted (Which they were deleted)

device# show crypto key mypubkey rsa

 and this command to show that the ecdsa keys were generated (Which they were generated)

device# show crypto key mypubkey ec

 But when I ran the "show ip ssh" command it stated that it could not find any RSA keys and to please generate RSA keys. But I had to reload the switch without saving the configuration to fix ssh afterward.

[lord0gnome]

Hello @OSUOPT 
Did you get this working finally ? We are having the same issue and I don't get the impression that this is truly supported yet.