SSH password-less authentication for file copying on Nexus 9k

Nexus 9000

If you do not have the option to use the write-memory command to send the configuration via ftp / tftp due to security reasons (information is send unencrypted) an great alternative is to use a scheduler and use secure copy to store your configuration on a linux host.

First things first let's activate the feature scp (if it isn't activated) yet, once this is done let's create the user and the ssh key that we will be using for storing the configuration.

Fig 1-1 Activate scp feature

Fig 1-2 Create username

Fig 1-3 Create key pair

Next step is to export the newly created key to the bootflash so you can copy the public key to your linux host and add it the the authorized_keys file.

Fig 1-4 Export the key to the bootflash

To protect your private key you will need to enter a passphrase and you will need to provide the passphrase when importing the key.

cs01.deca(config)# username adeca keypair import bootflash:adeca_rsa rsa force 

Enter Passphrase:

Fig 1-5 Import the key

Let's copy the public key to your linux host and add the key to the authorized_keys file which you can find in the subfolder .ssh in the home directory of the user you will be using to copy the files to.

cs01.deca# copy bootflash:adeca_rsa.pub    scp://adeca@10.255.255.200 vrf management

Fig 1-6 Copy the file

Let's check if the file has been successfully been copied to the linux host and pipe the contents of the file to the authorized_keys file.

cat adeca_rsa.pub >> .ssh/authorized_keys

Fig 1-7 Add key to authorized_keys file

You can verify if the key has been successfully added and that the key is the same as the one you have created in fig 1-3 .

Make sure you are logged in as the user where you have created the ssh key for (if you are not you will still need to provide password to login)

Fig 1-7 Ssh password-less authentication

Now you can log on without providing the password and this is what we need to schedule a recurring backup of your configuration.

What is important to understand if you create a scheduler schedule with a different username than the username that has the private/public key and is used to copy the files the scheduler will not succeed.

I need to verify if this is by design or if this could potentially be a bug.

Activate the feature scheduler and configure your scheduler job, which contains the statements you want to perform iteratively.

Fig 1-8 Scheduler configuration

You can test the job by just running this command and check if the command is executed successfully :)

Fig 1-9 Verification SSH password-less copying

Fig 1-10 Successful backup