SSH question - generate rsa key

[Melinbonian]

Hello

got a kind of stupid question.

Usually, when trying to access a normal server, we generate a key pair on a jumphost and move the public key to the server, so that we can always access the server from the jumphost (as per authentication).

I know that the command generate crypto rsa key generates public and private key, as per PKI. When we generate RSA key pair on a cisco router or firewall, how 'exactly' it works? Because we dont move any keys anywhere. I know we 'have' to generate it on every new device, to allow ssh, but im missing a key part of the theory on this, when i try to compare with normal ssh access to servers.

[Reza Sharifi]

It is saved in NVRAM

This command is not saved in the router configuration; however, the RSA keys generated by this command are saved in the private configuration in NVRAM (which is never displayed to the user or backed up to another device) the next time the configuration is written to NVRAM.

link:

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/security/a1/sec-a1-xe-3se-3850-cr-book/sec-a1-xe-3se-3850-cr-book_chapter_0110.html

HTH

[Karsten Iwen]

Perhaps one missing piece here is that for many communications involving public key cryptography, you need a key-pair on both the server and (depending what you want to do) also on the client.

[Melinbonian]

In this specific scenario though, how exactly does it work?

1. I go on the router, i type the command and generate public and private key on the router itself.

Does the public key somehow gets listed on the jumpserver (in known hosts)? I want to understand why the command itself is 'necessary' on a new appliance. I would expect that we would need to generate a key pair on the jumpserver and move the public key to the router, in order to authenticate the the jumpserver, but this is not the case.

[Karsten Iwen]

The purpose of the key generated on the router is that a client can be sure to connect to the correct server (the router is the SSH-server here). On the first connect you probably have seen your client asking if you want to trust this servers key represented by his fingerprint. Here we want to make sure that no man-in-the-middle is impersonating the server. After diligent test if this is really the right key, the key gets stored on the client in the known_hosts file. On the next connect the client sees that the presented public key is really the one that belongs to the server we want to connect to.

Next comes the user authentication. The server wants to know who connects to the server. Instead of using a password we can use public-key authentication. Now we need a key pair on the client. The public key gets transported to the server and is stored in an authorized_keys file. Whenever you connect to the server, the server asks the client to prove to have the corresponding private key to the one stored in authorized_keys. 

In short: The key-pair on the server is always needed to activate the SSH-server, the key-pair on the client is needed if you want to login with public-key authentication.