Configuration secrets

Passwords in SR Linux are protected using one-way hashing. Values stored using one-way hashing cannot be reversed; the plaintext form cannot be retrieved by the system. The hashed value is stored in the configuration.

SR Linux can verify a user password by comparing hashed password values. The system hashes the configured plaintext password and stores the hashed value in the configuration. During authentication, the system hashes the password the user enters with the same algorithm, then compares the result to the hashed value stored in the configuration. If they match, authentication succeeds.

Plaintext user passwords are encrypted using the default hashing method yescrypt. When entering a hashed password value, the system verifies whether the entered password is encrypted using one of the supported algorithms. The system only commits changes if the password has been hashed using a supported algorithm.

Password hashing is applied to all locally configured users, including the admin and the linuxadmin user. SR Linux supports yescrypt encryption in addition to the argon2 (ar2) and SHA512 (sha2) algorithms.

For the linuxadmin user password, only the sha2 and yescrypt encryption options are supported. If the ar2 encryption option is configured, the password is hashed using yescrypt instead.

Use the system aaa authentication password hash-method command to configure the algorithm used to hash user passwords.

--{ * candidate shared default }--[  ]--
# info with-context system aaa authentication password hash-method
    system {
        aaa {
            authentication {
                password {
                    hash-method ar2
                }
            }
        }
    }

Shared secrets are values that the router needs to recover in plaintext form to perform various protocol functions, such as peer authentication in routing protocols or RADIUS passwords. Shared secrets are protected in SR Linux using reversible encryption. The encrypted value is displayed and stored in the configuration.

SR Linux supports several encrypted formats for shared secrets. The first few characters (prefix) of the encrypted value indicate the format (for example, $aes1$ or $cryp3$). The following is an example.

--{ +* candidate shared default }--[  ]--
# info with-context network-instance default protocols bgp authentication
    network-instance default {
        protocols {
            bgp {
                authentication {
                    password $aes1$ATQyHDi8sc1ad28=$62q1s7X2WBBsCo2+Hf+McXWBVsL1VKRz7LipfWAeMdo=3
                }
            }
        }
    }

Both the $aes1$ and $cryp3$ formats use AES encryption.

The encryption key for $cryp3$ is derived from a user-created primary secret using PBKDF2. If a primary secret exists on the router, the system uses $cryp3$ for shared secrets. See Primary secret for more information.

A configuration file that contains $cryp3$ secrets cannot be copied from one router to another when each router has a unique primary secret. For chassis replacement, the same primary secret can be created on the new router, and the configuration file can then be copied over from the old router. Subsequently, the primary secret on the new router can be changed if needed.

SR Linux supports a user-configurable primary secret that is used to derive an encryption key for securing reversible shared secrets in the configuration.

You configure a primary secret using a tools command, as shown in the following example:

--{ +* candidate shared default }--[  ]--
# tools system storage-encryption primary-secret set-secret
Enter new-secret: <12-128 byte string>
Re-enter new-secret: <12-128 byte string>

When a primary secret is configured on a router, the $cryp3$ encryption format is used for securing shared secrets in the configuration. After a primary secret is created, the configuration file cannot be copied from one router to another. See Shared secrets for more information.

Setting or changing the primary secret causes the main configuration to be saved to disk. The primary secret itself is not stored in the configuration file, but it is persistent across reboots.

When first adding a primary secret or changing an existing primary secret, previous copies of the configuration (including checkpoints) remain on disk and have shared secrets protected with the method that was previously in use. If needed, those files must be manually deleted by an administrator.