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+).
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 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 (username linuxadmin, password linuxadmin) who has access to sudo to root and can run the SR Linux CLI with admin permissions. Other Linux users can be added with the useradd command in the underlying Linux OS.
Linux users 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+ server group.
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, which can be configured to authenticate local users using one or more authentication methods, including a local password and a TACACS+ server group. See Configuring authentication for local users for an example configuration.
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.
The SR Linux performs authentication, authorization, and accounting (AAA) functions for each user type, as described in the following sections.
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 Configuring 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.
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 given write access to all commands in the command tree.
See Configuring authorization for information about configuring roles for users.
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.
The following is an example of accounting records generated by the SR Linux device:
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:
See Configuring accounting for an example configuration.
The SR Linux supports the following server group types for AAA functions:
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.
Example:
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.
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.
By default, there is a single local user configured on the SR Linux, admin. You can configure additional local users.
Examples:
The following example configures a password for the SR Linux admin user:
The following example creates a local user called sruser and configures a password:
When the user configuration is displayed, the password is hashed; for example:
To change an existing user’s password, use the same command that created the user and configure the new password; for example:
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.
Authorization is performed through role-based access control. Users can be configured with a role that indicates the commands and access for which they are authorized.
A role consists of one or more rules, which specify a command string path and a corresponding action, which can be read, write, or deny. After authentication, a user is authorized to perform the specified action for the commands defined in the command string path for the role the user is assigned.
To configure a role, you define one or more rules that specify a path and a corresponding action. The path indicates the command string that is subject to authorization, and the action specifies the type of access for users assigned the role: read, write, or deny.
The path is specified as a command string relative to the root level. For example, the path “/” indicates all CLI commands at the root level and below; the path “/system” indicates all commands at the system level and below, and the path “/system configuration” indicates all commands at the system configuration level and below.
By default, a role named ntwkadmin is defined that specifies / as a path and write as the action. This means authenticated users configured with the role ntwkadmin have write access to all commands in the SR Linux command tree.
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 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 paths in a role does not matter; the longest match (most specific path) is used when validating a command against a path.The syntax for the path-reference is SR Linux CLI format, with “/” representing the root. Wildcards and ranges can be used with paths, in the same way they can in CLI syntax.
Each entry within the path list should use double quotes, unless the command string path 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\""
Examples:
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:
Then specify the rules under the system configuration role context:
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:
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:
A user can be assigned one or more roles. The rules configured in the role(s) 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 refer to the same path, the most specific rule is used.
Example:
In the following example, the user srlinux is assigned the role testrole:
Once 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 the previous section, this would authorize the srlinux user configure everything in the system except for the network-instance red.
When accounting is enabled, the SR Linux device generates command accounting records as described in Accounting.
Example:
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.
To display information about users currently logged in to the SR Linux device, use the show system aaa authentication session command.
Example:
The asterisk (*) next to the user name indicates the session from which the show system aaa authentication session was invoked.
To disconnect a user currently logged in to the SR Linux device, use the tools system aaa authentication session clear 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.
Example:
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.
Example:
The following example configures the idle-timeout so that SR Linux user sessions and remote user sessions are disconnected after 20 minutes of inactivity: