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

Nexus 9000

Suppose 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 sent unencrypted). In that case, a great alternative is to use a scheduler and use a 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

The next step is to export the newly created key to the boot flash so you can copy the public key to your Linux host and add it to 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.

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 successfully been copied to the Linux host and pipe the file's contents 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 for which you created the ssh key (if you are not, you will still need to provide a password to log in)

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.

It is essential to understand that if you create a scheduler schedule with a different username than the username with the private/public key and copy the files, the scheduler will not succeed.

I need to verify if this is by design or could 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 checking if the command is executed successfully :)

Fig 1-9 Verification SSH password-less copying

Fig 1-10 Successful backup