Tip

This is the documentation for the 24.06 version. Looking for the documentation of the latest version? Have a look here.

Changing Credentials and Keys¶

Organizations may have guidelines about how often to change credentials such as passwords and encryption keys. Different types of credentials and keys are stored in various places, and changing them can range from trivial or cumbersome depending on the type and how TNSR uses them.

These types of guidelines can vary widely based on various industry recommendations, certification standards, and other criteria. Due to these variations, this document won’t make any specific commentary on timing of such changes.

User Accounts ¶

Local user accounts on TNSR can be managed from within TNSR or in the OS. Users in the OS directly can be updated by following procedures in the OS documentation. Users created from within TNSR can be updated using the TNSR CLI or RESTCONF.

Passwords ¶

To change the password for a user created in the TNSR CLI, use the following sequence of commands:

tnsr# configure
tnsr(config)# auth user <user-name>
tnsr(config-auth)# password <plain text password>
tnsr(config-auth)# exit
tnsr(config)#

User Keys (ssh)¶

To update an SSH key for a user, either add a new key with a new name or replace the existing key.

tnsr# configure
tnsr(config)# auth user <user-name>
tnsr(config-auth)# user-keys <key-name>
[pasted key data]

tnsr(config-auth)# exit
tnsr(config)#

Certificate Data and Private Keys ¶

CA and Certificates have built-in expiration dates after which they must be generated again. For certificates, this is fairly low impact, but for a CA this can be more cumbersome as it also means re-creating the entire certificate structure.

The examples here show replacing an existing CA or certificate with a new copy. Another tactic is to create a new entry with a distinct name instead, though that is no different than creating a new certificate as described in Public Key Infrastructure.

CA ¶

Fully changing the private key and certificate requires erasing and regenerating all of its components.

First remove the old entries if they still exist in TNSR:

tnsr(config)# pki private-key selfca delete
tnsr(config)# pki signing-request selfca delete
tnsr(config)# pki certificate selfca delete

Note

Deleting the signing request is optional, but this is a good time to review and update the CA data.

Now create the CA again.

First, generate a new private key:

tnsr(config)# pki private-key selfca generate

Next, reconfigure the signing request if it was removed:

tnsr(config)# pki signing-request settings clear
tnsr(config)# pki signing-request set common-name selfca
tnsr(config)# pki signing-request set subject-alt-names add hostname selfca
tnsr(config)# pki signing-request set digest sha256
tnsr(config)# pki signing-request selfca generate

Finally, self-sign the CA:

tnsr(config)# pki signing-request selfca sign self purpose ca

Afterward, erase and re-create all of the certificates signed by this CA again.

Certificates ¶

Fully changing the private key and certificate requires erasing and regenerating all of its components.

First remove the old entries if they still exist in TNSR:

tnsr(config)# pki private-key myuser delete
tnsr(config)# pki signing-request myuser delete
tnsr(config)# pki certificate myuser delete

Note

Deleting the signing request is optional, but this is a good time to review and update the certificate data.

Now create the certificate again.

First, generate a new private key:

tnsr(config)# pki private-key myuser generate key-length 4096

Next, reconfigure the signing request if it was removed:

tnsr(config)# pki signing-request settings clear
tnsr(config)# pki signing-request set common-name myuser
tnsr(config)# pki signing-request set subject-alt-names add hostname myuser
tnsr(config)# pki signing-request set digest sha256
tnsr(config)# pki signing-request myuser generate

Finally, sign the certificate with a CA, such as the one re-created in the above example:

tnsr(config)# pki signing-request myuser sign ca-name selfca days-valid 365 digest sha512 purpose client

Copy the key and certificate output and securely distribute the certificate data to the user.

Alternately, to retain the private key and only renew the certificate, delete the old certificate and re-sign it. This assumes the signing request was still present.

tnsr(config)# pki certificate myuser delete
tnsr(config)# pki signing-request myuser sign ca-name selfca days-valid 365 digest sha512 purpose client

RESTCONF Server ¶

First generate a new copy of the server certificate as described in Certificate Data and Private Keys, then restart the RESTCONF server:

tnsr(config)# service restconf restart

VPNs ¶

For optimal security, changing VPN keys periodically is a good practice. The practicality of doing so largely depends on the size of the VPN (e.g. a simple two-site point-to-point link vs a remote access setup with dozens of users)

In any case, the most important thing is to coordinate the change with the remote peer(s) so all parties are using the correct keys.

IPsec ¶

Changing pre-shared key values is fairly simple but must be done in a coordinated fashion. As soon as one side changes the key, the other side will fail to negotiate the tunnel the next time it attempts to authenticate.

To change the key, update both the local and remote authentication rounds:

tnsr(config)# ipsec tunnel 0
tnsr(config-ipsec-tunnel)# crypto ike
tnsr(config-ipsec-crypto-ike)# authentication local
tnsr(config-ike-authentication)# round 1
tnsr(config-ike-authentication-round)# psk mynewsupersecretkey
tnsr(config-ike-authentication-round)# exit
tnsr(config-ike-authentication)# exit
tnsr(config-ipsec-crypto-ike)# authentication remote
tnsr(config-ike-authentication)# round 1
tnsr(config-ike-authentication-round)# psk mynewsupersecretkey
tnsr(config-ike-authentication-round)# exit
tnsr(config-ike-authentication)# exit
tnsr(config-ipsec-crypto-ike)# exit
tnsr(config-ipsec-tunnel)# exit
tnsr(config)#

WireGuard ¶

Changing pre-shared key values is fairly simple but must be done in a coordinated fashion. As soon as one side changes the key, the tunnel will fail.

Local Key¶

First, generate a new key from a shell prompt:

$ wg genkey | tee new.prv.key | wg pubkey > new.pub.key
$ cat new.prv.key
cALe8VHTm6tbe7pon0KtcOW8z3tC6mbkfEUV6HSGcUo=
$ cat new.pub.key
nPF7L6SV9xJBlpq3hZon4INbRoI7N2nUSQtKF3/fVFw=

Then add the new key into the configuration:

tnsr(config)# interface wireguard 1
tnsr(config-wireguard)# private-key base64 cALe8VHTm6tbe7pon0KtcOW8z3tC6mbkfEUV6HSGcUo=
tnsr(config-wireguard)# exit

Finally, deliver the new public key to the remote peer(s) so they can update their configuration(s).

Peer Key¶

If a peer sends a new public key, replace the existing key for the peer with the new key:

tnsr(config)# interface wireguard 1
tnsr(config-wireguard)# peer 1
tnsr(config-wireguard-peer)# public-key base64 SATd3LG2A+h7YA8a3+SB7z/0ipG7mkE1yEavdczKthI=
tnsr(config-wireguard-peer)# exit
tnsr(config-wireguard)# exit

Dynamic Routing ¶

Various components of dynamic routing utilize authentication mechanisms to ensure they are communicating with the correct peers. In most cases these are optional.

When updating these authentication parameters, both sides will need to start using the new credentials at the same time.

BGP Neighbor Password ¶

tnsr(config)# route dynamic bgp
tnsr(config-frr-bgp)# server vrf <vrf-name>
tnsr(config-bgp)# neighbor <peer>
tnsr(config-bgp-neighbor)# password <new-password>
tnsr(config-bgp-neighbor)# exit
tnsr(config-bgp)# exit
tnsr(config-frr-bgp)# exit

OSPF message-digest-key ¶

Change the credentials for OSPF instances using MD5 HMAC digest authentication as follows:

tnsr(config)# route dynamic ospf
tnsr(config-frr-ospf)# interface <if>
tnsr(config-ospf-if)# ip address (*|<addr>) message-digest-key key-id <id> md5-key <key>
tnsr(config-ospf-if)# exit
tnsr(config-frr-ospf)# exit

OSPF authentication-key ¶

Change the credentials for OSPF instances using simple password-based authentication as follows:

tnsr(config)# route dynamic ospf
tnsr(config-frr-ospf)# interface <if>
tnsr(config-ospf-if)# ip address (*|<addr>) authentication-key <key>
tnsr(config-ospf-if)# exit
tnsr(config-frr-ospf)# exit

RIP Key ¶

Change the RIP key chain string as follows:

tnsr(config)# route dynamic rip
tnsr(config-frr-rip)# key-chain <name>
tnsr(config-rip-key-chain)# key <key-id> string <key-string>
tnsr(config-rip-key-chain)# exit
tnsr(config-frr-rip)# exit

BFD Keys ¶

To update the secret on an existing key:

tnsr(config)# bfd conf-key-id <conf-key-id>
tnsr(config-bfd-key)# secret <new secret>

SNMP ¶

SNMP Communities ¶

An SNMP community in SNMPv1 and SNMPv2c is similar to a username and password in a single string, and as such it may need to be changed. The community name cannot be changed in-place, so define a new community with the same parameters as the old entry, then remove the old entry. Repeat as needed for additional sources or other parameters.

tnsr(config)# snmp community community-name <community-name>
                             source (<src-prefix>|default)
                             security-name <security-name>
tnsr(config)# no snmp community community-name <old-community>