Securing access

The SR Linux is able to secure access to the device for users connecting via SSH or the console port, as well as for applications and FTP access. Authentication can be performed for users configured within the underlying Linux OS, and for administrative users configured within the SR Linux itself.

Depending on the user type, users are authenticated locally on the device or through interaction with the SR Linux aaa_mgr application and an authentication server group (for example, TACACS+).

User types

The SR Linux supports three user types: Linux users, local users, and remote users. Each user type is authenticated differently, as described in the following sections.

Linux users

Linux users are those configured in the underlying Linux OS, not in the SR Linux CLI. Information about Linux users is stored in /etc/passwd in the underlying Linux OS.

By default, the SR Linux has a single Linux user, linuxadmin, who has access to sudo to root and can run the SR Linux CLI with admin permissions. The default password for the linuxadmin user is NokiaSrl1!, which you can change using the SR Linux CLI; see Configuring the password for the linuxadmin user. Nokia recommends that you change this default password as soon as possible. Other Linux users can be added with the useradd command in the underlying Linux OS.

Linux users, as long as they have a UID less than 1500, are authenticated via the underlying Linux OS, not through the SR Linux aaa_mgr application. This means that Linux users are not subject to authentication settings configured within the SR Linux CLI, such as authentication by a TACACS+/RADIUS server group or password security for local users.

Local users

Local users are users configured within the SR Linux itself. By default, SR Linux supports a single local user, named admin; other local users can be added as necessary.

Local users are authenticated via a gRPC interface to the aaa_mgr application. See Authentication for local users for an example configuration.

Remote users

Remote users are users that are not configured either in /etc/passwd or within the SR Linux configuration. Remote users are configured on a remote server, which is queried when the user attempts to log in to the SR Linux device.

AAA functions

The SR Linux performs authentication, authorization, and accounting (AAA) functions for each user type, as described in the following sections.

Authentication

For Linux users, the SR Linux authenticates via the authentication mechanism built into the underlying Linux OS.

For local users, including the SR Linux admin user, the SR Linux uses its gRPC interface to the aaa_mgr application for authentication. Authentication settings that apply to the local users, including a local password and TACACS+ server group, can be configured using the SR Linux CLI. See Authentication for local users for information about configuring local users.

For remote users, authentication is performed using the aaa_mgr application in coordination with the remote system.

Password security for local users

SR Linux supports password security features that apply to local users who authenticate using plain text passwords. The settings are system-wide configurations that apply to all locally configured users including the admin user, but excluding the linuxadmin user. The following password security features are supported:

  • Password complexity rules

    Specifies rules that define the password requirements, including minimum and maximum length, minimum lowercase and uppercase characters, minimum numeric and special characters, and whether the password can include the user's full username or only the first three characters. The configuration of password complexity rules applies only to new passwords entered as clear text, not to pre-existing or pre-hashed ones.

  • Password aging

    Specifies the number of days after which a password will expire.

    Note:
    • Users with aged out passwords are prompted to update their password at the next login to the CLI. (This prompt appears on the CLI only.)
    • SR Linux does not provide advanced warning to users that their password is about to expire.
    • Aged out passwords expire indefinitely. They are not controlled by the lockout policy described below.

  • Password change on first login

    Specifies whether local users must change their password on first login. The new password must match the defined password complexity rules.

  • Password history

    Specifies the number of previous user passwords SR Linux retains to prevent reuse of old passwords.

  • Lockout policy

    Specifies how many times a user can attempt a failed login within a defined period before they are locked out (for example: three attempts within 1 minute). The policy also defines whether the user is locked out indefinitely or only for a specified length of time.

Authorization

The SR Linux implements authorization through role-based access control, where each authenticated user is assigned one or more predefined roles that specify the functions the user is allowed to perform on the system. If no role is configured for a user, then the user is assigned a role that allows access to CLI plugins, but no other functions.

Authorization via role based access control is performed for all user types on all interfaces (CLI, gNMI, JSON-RPC), with the exception of the admin and linuxadmin users, which are permitted write access to all commands in the command tree. You can configure service authorization, which can limit the interface types for which the functions in a role are authorized.

You can configure the SR Linux to use information from a TACACS+ server to assign roles to an authenticated user. In this case, the priv-lvl value in the authorization-reply message received from the TACACS+ server maps to a role configured on the SR Linux. The user is assigned the role that corresponds to the priv-lvl value.

See Authorization using role-based access control for information about configuring roles for users.

Accounting

The SR Linux supports command accounting. Accounting records generated by the SR Linux include the entire CLI string that a user enters on the command line, including any pipes or output redirects specified in the command.

You can configure the SR Linux device to send accounting records to a destination specified in an accounting-method list, such as a TACACS+ server group or the local system.

For each user type, the SR Linux device generates accounting records as follows:

  • For local users, including the SR Linux admin user, command accounting records are sent to the destination specified in the accounting-method list, both for commands entered in the SR Linux CLI and for commands entered in the bash shell.

  • For Linux users and remote users, command accounting records are sent for commands entered in the SR Linux CLI (including Linux commands entered in the SR Linux CLI using the bash command), although not for commands entered in the bash shell.

See Configuring accounting for an example configuration.

AAA server group configuration

The SR Linux supports the following server group types for AAA functions:

  • local – Uses local authentication, including /etc/passwd, /etc/group, and logging via syslog.

  • TACACS+ – Performs authentication, authorization, and accounting via interaction with servers in a TACACS+ server group.

Users whose AAA functions are handled by the aaa_mgr application (that is, the SR Linux admin user and local users) can use one of these server groups for authentication and accounting.

The TACACS+ server group can have up to five servers. When authenticating a user or writing an accounting record, the SR Linux tries each server in the group in a round-robin fashion until a response is received. If no response is received within a specified timeout period, the SR Linux tries the next server in the group.

If no response is received from any of the servers in the group, the SR Linux moves to the next specified authentication or accounting method. If no other method is specified, or the TACACS+ server group is the last method in the list, then the authentication or accounting request is rejected.

Configuring an AAA server group

The following example shows settings for a TACACS+ and a local server group to be used for AAA functions. TACACS+ requests are sourced from the mgmt network-instance.

The TACACS+ server group consists of three TACACS+ servers. The timeout period specifies that the SR Linux wait 30 seconds for a response from a server before trying the next server in the group.

For the server group of type local, no external servers can be specified. The local server group uses /etc/passwd and /etc/group for authentication, and syslog for accounting. The timeout period specifies that the SR Linux wait a maximum of 60 seconds for an AAA function to complete.

--{ * candidate shared default }--[  ]--
# info system aaa
 system {
     aaa {
         server-group tacacs-all {
            type tacacs
            timeout 30
            server 1.2.2.1 {
                network-instance mgmt
                tacacs {
                    secret-key $aes$3/Iz5veTDRV0=$6GxkrGjFbqWbYMA0T3itgQ==
                }
            }
            server 1.2.2.2 {
                network-instance mgmt
                tacacs {
                    secret-key $aes$3/Iz5veTDRV0=$6GxkrGjFbqWbYMA0T3itgQ==
                }
            }
            server 1.2.2.3 {
                network-instance mgmt
                tacacs {
                    secret-key $aes$3/Iz5veTDRV0=$6GxkrGjFbqWbYMA0T3itgQ==
                }
            }
         server-group local {
            type local
            timeout 60
            }
         }
     }
 }

Authentication for the linuxadmin user

The SR Linux linuxadmin user is installed by default in /etc/passwd. The linuxadmin user has access to sudo to root and can run the SR Linux CLI with admin permissions.

The default password for the linuxadmin user is NokiaSrl1!. You can change this password via the SR Linux CLI or any other supported interface.

Configuring the password for the linuxadmin user

Use the following command to set the password for the linuxadmin user.

--{ * candidate shared default }--[  ]--
# system aaa authentication linuxadmin-user password NewPass1234

When the user configuration is displayed, the password is hashed; for example:

--{ * candidate shared default }--[  ]--
# info system aaa authentication linuxadmin-user
    system {
        aaa {
            authentication {
                linuxadmin-user {
                    password $6$d091a49828c4cc87$CGe7QbxzZm/WadeMYF
                }
            }
        }
    }

Authentication for local users

Local users are those configured within the SR Linux CLI. For a local user, you can configure a password and specify one or more authentication methods, including local authentication or a TACACS+ server group.

Configuring authentication for local users

By default, there is a single local user configured on the SR Linux, admin. You can configure additional local users.

The following example configures a password for the SR Linux admin user:

--{ * candidate shared default }--[  ]--
# system aaa authentication admin-user password NewPass1234

The following example creates a local user called sruser and configures a password:

--{ * candidate shared default }--[  ]--
# system aaa authentication user srlinux password sr1l234

When the user configuration is displayed, the password is hashed; for example:

--{ * candidate shared default }--[  ]--
# info system aaa
    system {
        aaa {
            authentication {
                user srlinux {
                    password $ar2$KGSITqfJu5g=$iZZ6XKXtXOZOGMbeXO2ypg==
                }
            }
        }
    }

To change an existing user’s password, use the same command that created the user and configure the new password; for example:

--{ * candidate shared default }--[  ]--
# system aaa authentication user srlinux password NewPasswordl234

The following example specifies authentication methods. When a user attempts to log in, the user is authenticated using local authentication first. If local authentication fails, the SR Linux tries the servers in TACACS+ server group tacacs-all. If the user cannot be authenticated through either method, the authentication attempt is rejected.

--{ * candidate shared default }--[  ]--
# info system aaa
 system {
     aaa {
         authentication {
            authentication-method [
                local
                tacacs-all
            ]
         }
     }
 }

Configuring password security for local users

Password security and user lockout settings apply to all local users who authenticate using plain text passwords including the admin user.

To configure password security and user lockout features, set the following parameters under system aaa authentication:

  • password aging <0 to 500>

    Sets the number of days after which the user password expires and the user is prompted to update their password. The default of 0 sets the password to never expire.

  • password change-on-first-login [true | false]

    When set to true, forces local users to change their password on the first login to the system. The default is false.

  • password history <0 to 20>

    Specifies how many previous passwords SR Linux matches a new password against, such that the new password cannot be one of the previous <0 to 20> passwords. The default is 0, which disables password history.

  • password complexity-rules

    Sets the complexity rules that new passwords must match, using the following options:

    • minimum-length <1 to 12>

      Sets the minimum password length. The default is 1, which applies no minimum.

    • maximum-length <1 to 1023>.

      Sets the maximum password length. The default is 1, which applies no maximum.

    • minimum-lowercase <0 to 10>

      Sets the minimum required lowercase characters. The default is 0, which applies no minimum.

    • minimum-uppercase <0 to 10>

      Sets the minimum required uppercase characters. The default is 0, which applies no minimum.

    • minimum-numeric <0 to 10>

      Sets the minimum required numeric characters. The default is 0, which applies no minimum.

    • minimum-special-character <0 to 10>

      Sets the minimum required special characters: (!"#$%&'()*+,-./:;<=>?@[\]^_`{|}~"). The default is 0, which applies no minimum.

      Note: Users must enter the double quote as \" and the backslash as \\.
    • allow-user-name [true | false]

      Specifies whether the user can include their username as part of their password. If set to false, then SR Linux allows only the first three consecutive characters of the username in the user password. The default is true, which allows the password to contain the full username.

  • password lockout-policy

    Specifies the user lockout policy using the following parameters:

    • attempts <0 to 64>

      Sets the number of failed login attempts that trigger the lockout. The default is 0, which allows unlimited failed login attempts.

    • time <0 to 1440>

      Sets the time period in minutes within which the failed login attempts must occur to trigger the lockout. The timer starts at the first failure. The default is 1 minute.

    • lockout <0 to 1440>

      Sets the time period in minutes during which the user account remains locked out. A value of 0 means that the user account is locked out indefinitely. The default is 15 minutes.

Configure password security and user lockout

The following example sets the following password security and user lockout settings:
  • User passwords expire after 365 days.
  • Users must change their password on first login.
  • Users cannot reuse any of their 10 previous passwords.
  • Passwords must contain:
    • A minimum of eight and a maximum of 16 characters.
    • One each of lowercase, uppercase, numeric, and special characters.
  • Usernames are not allowed in the passwords.
  • After five failed attempts within 2 minutes, users are locked out indefinitely.
--{ * candidate shared default }--[ ]--
# info aaa authentication password
    aaa {
        authentication {
            password {
                aging 365
                change-on-first-login true
                history 10
                complexity-rules {
                    minimum-length 8
                    maximum-length 16
                    minimum-lowercase 1
                    minimum-uppercase 1
                    minimum-numeric 1
                    minimum-special-character 1
                    allow-username false
                }
                lockout-policy {
                    attempts 5
                    time 2
                    lockout 0
                }
            }
        }
    }

Clear local user lockout

To display locked out users, use the info from state system aaa authentication command, which displays a lockout state of active true when a user is locked out.

To clear a local user's lockout state, use the following tools command:

tools system aaa authentication user <username> unlock

Display user lockout state

--{ * candidate shared default }--[ ]--
#info from state system aaa authentication  
    system {
        aaa {
            authentication {
                exit-on-reject false
                idle-timeout 600
                authentication-method [
                    local
                ]
                user srl-test-1 {
                    password $bt$Vbf0Zgg8MGP=$ihHklTQHi/+3VwVD04Z8gh==
                    failed-login-attempts 10
                    last-failed-login 2022-07-29T22:35:23.801Z
                    password-change-required true
                    role [
                        test
                    ]
                    lockout {
                        active true
                        start 2022-07-29T22:35:23.801Z
                        end "14 minutes from now"
                    }
                }
                user srl-test-2 {
                    password $bt2$jBZBL6WAuTr=$eXYWpivE5z10YxBIZ06hjQ==
                    password-change-required true
                    role [
                        test
                    ]
                }

Clear user lockout state

--{ * candidate shared default }--[ ]--
#tools system aaa authentication user srl-test-1 unlock
/system/aaa/authentication/user[username=srl-test-1]:
    Unlocked user srl-test-1

Authorization using role-based access control

Authorization is performed through role-based access control. Users can be configured with a set of one or more roles that indicate the privileges for which they are authorized in the system.

A role consists of one or more rules, which specify a schema path the role can have privileges for, and a corresponding action, which can be read, write, or deny. After authentication, a user is authorized to perform the specified action defined in the path for the role the user is assigned.

Role-based access control supports service authorization, which allows you to limit the actions a user is authorized to perform to specific access types such as CLI and gNMI.

Role configuration

Roles consist of a set of rules that define a schema path-reference and a corresponding action. The path-reference specifies system functions that are subject to authorization, and the action specifies the privilege type for users assigned the role: read, write, or deny.

The path-reference is specified relative to the root level. For example, the path-reference ‟/” indicates all CLI functions at the root level and below; the path-reference ‟/system” indicates all CLI functions at the system level and below, and the path-reference ‟/system configuration” indicates all CLI functions at the system configuration level and below.

If no role is assigned to a user at login, the user has access to all CLI plugins, but no access to CLI commands at any level. This is equivalent to a rule with / as the path-reference and deny as the action.

Up to 32 roles are supported; each role can have a list of up to 256 paths. The order of the path-references in a role does not matter; the longest match is used when validating a command against a path-reference.

The syntax for the path-reference is SR Linux CLI format, with ‟/” representing the root. Wildcards and ranges can be used with path-references, in the same way they can in CLI syntax.

Each entry within the path-reference should use double quotes, unless the command string is a single word with no spaces. If the path itself includes quotes, use backslash characters to indicate the quotes. For example, to specify the following in a path-reference:

a "b" and c "d"

You can configure the following for the path-reference:

path-reference "a \"b\"" "c \"d\""

Configuring a role

To configure a role, you define one or more rules that specify a path indicating the command string that is subject to authorization, and a corresponding action such as read, write, or deny.

The following is an example of creating a role named testrole that contains two rules: one rule to limit access to network-instance red, and another rule to give write access to the rest of the tree. A user assigned this role upon authentication is able to configure everything in the system except network-instance red.

First, define the role under the system aaa authorization context:

--{ * candidate shared default }--[  ]--
# info system aaa
    system {
        aaa {
            authorization {
                role testrole {
                }
            }
        }
    }

Then specify the rules under the system configuration role context:

--{ * candidate shared default }--[  ]--
# info system configuration
    system {
        configuration {
            role testrole {
                rule / {
                    action write
                }
                rule "network-instance red" {
                    action read
                }
            }
        }
    }

The following example configures a role named acl_app that allows a user to view the state of the acl_mgr application, but no other information:

--{ * candidate shared default }--[  ]--
# info system aaa
    system {
        aaa {
            authorization {
                role acl_app {
                }
            }
        }
    }

--{ * candidate shared default }--[  ]--
# info system configuration
    system {
        configuration {
            role acl_app {
                rule system {
                    action deny
                }
                rule "system app-management application acl_mgr state" {
                    action read
                }
            }
        }
    }

When a user that is assigned the acl_app role attempts to read information from the system state datastore, only the state of the acl_mgr application is displayed. For example:

--{ * candidate shared default }--[  ]--
# info from state system application acl_mgr
system {
    app-management {
        application acl_mgr {
            state running
        }
    }
}

Assigning roles to users

A user can be assigned one or more roles. The rules configured in the user's roles specify the commands the user is authorized to issue.

Up to 32 roles can be assigned to a user. If a user has multiple roles assigned, all of the rules configured in all of the roles apply to the user. If multiple roles reference the same path, the most specific rule is used.

For service authorization, the system merges all roles that have the service (CLI, gNMI, and so on) the user has logged in with, and excludes any roles that omit the service.

In the following example, the user srlinux is assigned the role testrole.

After the srlinux user is authenticated, the user is authorized to use the system according to the rules configured in the role testrole. Using the example from Configuring a role, this would authorize the srlinux user to configure everything in the system except for the network-instance red.

--{ * candidate shared default }--[  ]--
# info system aaa
    system {
        aaa {
            authentication {
                user srlinux {
                    role [
                        testrole
                    ]
                }
            }
        }
    }

Authorization using a TACACS+ server

You can configure the SR Linux to use a TACACS+ server to provide authorization for role-based access control. When TACACS+ authorization is configured, the actions an authenticated user can perform depend on the priv-lvl value configured for the user on a TACACS+ server. If priv-lvl-authorization is not set to true, the authenticated user is authorized as an admin user.

TACACS+ authorization for SR Linux users works as follows:

  1. After a user is authenticated, the SR Linux sends the TACACS+ server an authorization-request message based on a shell (exec) session starting. This authorization-request is sent immediately following user authentication, but before the shell is started.

  2. The TACACS+ server returns an authorization-reply message that includes the priv-lvl value configured for the user for shell access.

  3. On the SR Linux, roles have been configured that map to a priv-lvl value.

  4. The SR Linux allows the user to perform actions specified in roles with a priv-lvl value equal or lower to the priv-lvl value returned by the TACACS+ server.

Configuring TACACS+ Authorization

To configure TACACS+ authorization for SR Linux users, you enable priv-lvl authorization for the TACACS+ server group and configure roles that specify the priv-lvl mapping for each role subject to authorization using a TACACS+ server.

The following configuration enables priv-lvl authorization for the tacacs-all server group:

--{ * candidate shared default }--[  ]--
# info system aaa server-group tacacs-all
    system {
        aaa {
            server-group tacacs-all {
                priv-lvl-authorization true
            }
        }
    }

The following configuration specifies two roles, interface oper-state and network-instance oper-state. The interface oper-state role grants read access for all interface oper-states, and the network-instance oper-state role grants read access for all network-instance oper-states. 

--{ * candidate shared default }--[  ]--
# info system configuration role *
    system {
        configuration {
            role "interface oper-state" {
                rule "interface * oper-state" {
                    action read
                }
            }
            role "network-instance oper-state" {
                rule "network-instance * oper-state" {
                    action read
                }
            }
        }

The following configuration specifies the priv-lvl mapping for both roles.

In this example, when a user is authenticated, the SR Linux sends an authorization-request based on a shell (exec) session starting. The TACACS+ server returns an authorization-reply that specifies the priv-lvl value for the shell.

If the priv-lvl value returned by the TACACS+ server is 14, the user is assigned both roles; that is, read access to all interface oper-states and all network-instance oper-states, but no access to anything else in the system.

If the priv-lvl value returned by the TACACS+ server is 13, the user is assigned only the network-instance oper-state role and can read the oper-state for network-instances, but has no access to anything else in the system.

--{ * candidate shared default }--[  ]--
# info system aaa authorization
    system {
        aaa {
            authorization {
                role "interface oper-state" {
                    tacacs {
                        priv-lvl 14
                    }
                }
                role "network-instance oper-state" {
                    tacacs {
                        priv-lvl 13
                    }
                }
            }
        }
    }

The following example configures service authorization for a role that uses TACACS+ authorization. See Configuring service authorization.

In this example, when a user is authenticated by a TACACS+ server in the server group tacacs-all, if the TACACS server returns priv-lvl 15 for the user, then role_1 is assigned to the user.

Service authorization is configured for the role so that all services except gNMI are authorized for users assigned this role. This means users assigned role_1 are authorized for the functionality defined in the rules of role_1 if they connect using the CLI, JSON-RPC, or FTP, but are not authenticated if they connect using gNMI.

--{ * candidate shared default }--[  ]--
# info system aaa authorization role role_1
    system {
        aaa {
            authorization {
                role role_1 {
                    services [
                        cli
                        json-rpc
                        ftp
                    ]
                    tacacs {
                        priv-lvl 15
                    }
                }
            }
        }
    }

When a user is assigned multiple roles, the user is authorized for all services specified in the roles they are assigned, according to the rules defined in the roles. For example, if a user is assigned role_1, which allows access to the system via CLI, and also assigned role_2, which allows access via gNMI, the user is authorized to use the CLI to perform the functions defined in the rules of role_1, and is authorized to use the gNMI interface for the functions defined in the rules of role_2.

Service authorization for local users

Service authorization allows you to block or allow access to a user depending on the interface they use to connect to the device. You can use service authorization to restrict access to a controller, allowing it to speak through programmatic interfaces, but without credentials that can be used by someone logged into the CLI.

To configure service authorization, you assign roles to local users that authorize them to issue commands using specified services, such as the CLI, gNMI, or JSON-RPC interfaces. For example, you can define a role that grants read access to subinterface statistics, and limits access to that information to the gNMI service. When you assign that role to a user, the user is allowed to read subinterface information via the gNMI interface only.

The following interface types can be configured for service authorization:

  • cli - access to the system via CLI
  • gnmi - access to the system via gNMI
  • json-rpc - access to the system via JSON-RPC
  • ftp - access to the system via FTP
  • p4rt - access to the system via P4Runtime RPCs

After a user is authenticated, the system checks whether the user is assigned a role that allows access via the interface they used to connect to the device. For example, if a user connects using gNMI, the system checks whether the user is assigned any roles that authorize access via the gNMI interface. If the user is assigned a role that authorizes access via gNMI, the user receives access to the system via gNMI according to the rules defined in the set of roles that includes gNMI. If the user connects via gNMI, but is not assigned any role that authorizes access via gNMI, the authorization attempt is rejected and the session is closed.

If a user is assigned multiple roles, the user is authorized for all services specified in the roles they are assigned, according to the rules defined in the roles. For example, consider a user assigned role r1, which allows access to the system via CLI, and also assigned role r2, which allows access via gNMI. The user is authorized to use the CLI to perform the functions defined in the rules of role r1, and is authorized to use the gNMI interface for the functions defined in the rules of role r2.

By default, a role has no services configured for authorization. When you configure a role, you must specify the services that apply to the role. Users assigned the role are authorized to perform the functions defined in the role using the specified services.

Configuring service authorization

To configure service authorization, you create a role that defines rules permitting or denying access to system functionality, assign the role to one or more users, and specify the services over which users assigned the role are authorized to perform the rules defined in the role.

The following example creates a role read-oper-state that allows reading subinterface oper-state but nothing else:

--{ * candidate shared default }--[  ]--
# info system configuration role *
    system {
        configuration {
            role read-oper-state {
                rule / {
                    action deny
                }
                rule "interface * subinterface * oper-state" {
                    action read
                }
            }
        }
    }

The following example creates a user gnmiuser that is assigned the read-oper-state role when authenticated:

--{ * candidate shared default }--[  ]--
# info system aaa authentication
    system {
        aaa {
            authentication {
                authentication-method [
                    local
                ]
                user gnmiuser {
                    role [
                        read-oper-state
                    ]
                }
            }
        }
    }

The following example configures service authorization so that users assigned the read-oper-state role, such as gnmiuser, can perform the functionality defined in the role only if they have connected to the system via gNMI. If the user connects via a different service, such as by logging into the CLI, the user is not authorized for the functionality defined in the role.

--{ * candidate shared default }--[  ]--
# info system aaa authorization
    system {
        aaa {
            authorization {
                role read-oper-state {
                    services [
                        gnmi
                    ]
                }
            }
        }
    }

Accounting configuration

When accounting is enabled, the SR Linux device generates command accounting records as described in Accounting.

The following is an example of accounting records generated by the SR Linux device:

Aug 7 22:34:09
127.0.0.1 bob ssh 172.17.0.1 start task_id=2 timezone=UTC service=shell priv-lvl=15 
cmd=tail -f /var/log/tac_plus.acct
Aug 7 22:34:09
127.0.0.1 bob ssh 172.17.0.1 stop task_id=2 timezone=UTC service=shell priv-lvl=15 
cmd=tail -f /var/log/tac_plus.acct
Aug 7 22:34:14
127.0.0.1 bob ssh 172.17.0.1 start task_id=5 timezone=UTC service=shell priv-lvl=15 
cmd=help
Aug 7 22:34:14
127.0.0.1 bob ssh 172.17.0.1 stop task_id=5 timezone=UTC service=shell priv-lvl=15 
cmd=help

Configuring accounting

The following example configures accounting records to be sent to the tacacs-all server group. The SR Linux generates an accounting record when a command is started and when it is stopped.

--{ * candidate shared default }--[  ]--
# info system aaa
 system {
     aaa {
         accounting {
            accounting-method [
                tacacs-all
            ]
            event commands {
                record start-stop
            }
         }
     }
 }

Displaying user session information

To display information about users currently logged in to the SR Linux device, use the show system aaa authentication session command.

# show system aaa authentication session
+----+-------+-------------+----------------+----------+-------+-------------+---------------------+
| ID | User  |   Service   | Authentication | Priv-lvl |  TTY  | Remote  |      Login time         |
|    | name  |    name     |     method     |          |       |  host   |                         |
+====+=======+=============+================+==========+=======+=========+=========================+
| 4  | bob   | srlinux-cli |    tacacs      |    15    | pts/1 | 2.1.0.2 | 2021-12-06T21:24:07.80Z |
| 11 | user* | srlinux-cli |    local       |          | pts/4 |         | 2021-12-07T04:06:06.93Z |
+----+-------+-------------+----------------+----------+-------+---------+-------------------------+

The asterisk (*) next to the username indicates the session from which the show system aaa authentication session was invoked.

Disconnecting user sessions

To disconnect a user currently logged in to the SR Linux device, use the tools system disconnect session-id <session-id> command and specify the session ID of the user. To list the session IDs of active users, enter the show system aaa authentication session command.

# show system aaa authentication session
+----+-------+-------------+----------------+----------+-------+-------------+---------------------+
| ID | User  |   Service   | Authentication | Priv-lvl |  TTY  | Remote  |      Login time         |
|    | name  |    name     |     method     |          |       |  host   |                         |
+====+=======+=============+================+==========+=======+=========+=========================+
| 6  | bob   | srlinux-cli |    tacacs      |    15    | pts/1 | 2.1.0.2 | 2021-12-06T21:24:07.80Z |
| 11 | user* | srlinux-cli |    local       |          | pts/4 |         | 2021-12-07T04:06:06.93Z |
+----+-------+-------------+----------------+----------+-------+---------+-------------------------+

# tools system disconnect session-id 6
Terminating cli session 6 owned by user 'bob' logged from pts/1
/system/aaa/authentication/session[id=6]:
    Disconnecting aaa cli session(s): 6

Configuring idle-timeout for user sessions

You can configure the idle-timeout for user sessions, which disconnects a user session after a specified period of inactivity. By default, user sessions are disconnected after 15 minutes of inactivity.

The idle-timeout setting applies to SR Linux users and remote users. It does not apply to Linux users or to JSON-RPC or gNMI client sessions.

After a user session has been inactive for one-half of the idle-timeout period, a notification is displayed indicating that the user will be logged out if the session remains idle for the remainder of the idle-timeout period.

The following example configures the idle-timeout so that SR Linux user sessions and remote user sessions are disconnected after 20 minutes of inactivity:

--{ * candidate shared default }--[  ]--
# info system aaa
 system {
     aaa {
         authentication {
            idle-timeout 20
            }
         }
     }
 }