Users¶

Overview¶

Two user roles are available by default:

viewer for use in operational mode where the configuration cannot be changed, only commands to troubleshoot or monitor are available.

This is the default role for new users.
admin for use in configuration mode, with full access.

It is also possible to configure custom user roles. See Managing User Roles.

Three user accounts are provided by default:

Account	Default password	Description
`admin`	`admin`	The standard account for configuration. It has the `admin` role.
`viewer`	`viewer`	A restricted account for monitoring purposes. It has the `viewer` role.
`root`	`6windos`	Provides the ability to log into the Linux subsystem as superuser. Note that any configuration or customization of the Virtual Service Router in this mode is out of the support scope, may break the system, and will be lost after an update.

Warning

For security reasons, it is recommended to change the default passwords of preconfigured users. See Changing Passwords.

Two default users are created when booting the system for the first time: admin and viewer. Their default passwords are admin and viewer, respectively.

The admin account has the admin role, which means that it has permissions to edit the configuration and run privileged commands.

The viewer acccount has the viewer role, which means that it has permissions to view the configuration but not to edit it and run standard commands.

Warning

For obvious security reasons, you MUST change the passwords of these users.

You may even want to completely disable the default admin and viewer users, by setting default-users-enabled to false:

vsr running config# system auth default-users-enabled false
vsr running config# commit
Configuration applied.

In this case, you must configure a user with the admin role, else you will lose access to the CLI.

Changing Passwords¶

CLI users¶

To change the admin user password, go in the system auth user admin context:

vsr running config# system auth user admin
vsr running user admin#! role admin
vsr running user admin# password
Enter value for password> **********
vsr running user admin# commit
Configuration applied.

For security reasons, the password is not stored in clear-text in the configuration. A hash is stored instead.

vsr running user admin# show config
user admin
    role admin
    password $5$Ndx/QlMS5Anp7LTq$Lws2OmAm0SO.cBmPBGtdpwnfdAM4hDM4AdSO4ncXjS/

It is also possible to directly set the password as a hashed value. To generate a hashed password on a Linux machine, use mkpasswd, which is provided in the whois package:

root@host:~# mkpasswd -m SHA-256
Password: **********
$5$Ndx/QlMS5Anp7LTq$Lws2OmAm0SO.cBmPBGtdpwnfdAM4hDM4AdSO4ncXjS/

`root` user¶

Changing the password for the root user is done through the Linux shell:

root@vsr:~# passwd
Enter new UNIX password: ********
Retype new UNIX password: ********
passwd: password updated successfully

Creating Users¶

To create a new user, go into the config system auth context, and add a new user with the following commands:

vsr running user admin# ..
vsr running auth# user john
vsr running user john# role admin
vsr running user john# password
Enter value for password> **********
vsr running user john# commit
Configuration applied.

Let’s display what has been sent to the NETCONF server:

vsr running user john# show config xml absolute
<config xmlns="urn:6wind:vrouter">
  <system xmlns="urn:6wind:vrouter/system">
    <auth xmlns="urn:6wind:vrouter/system/auth">
      <user>
        <name>john</name>
        <role>admin</role>
        <password>$5$iqsVCbCmIYRF.Sht$lCwP.HDLxtTnzz33uXX7ZdTR6xdSdnUoabRMxHYXjI9</password>
      </user>
    </auth>
  </system>
</config>

Now that the configuration is applied, let’s see the state of our user:

vsr running user john# show state
user john
    password $5$iqsVCbCmIYRF.Sht$lCwP.HDLxtTnzz33uXX7ZdTR6xdSdnUoabRMxHYXjI9
    role admin
    ..

The user john has the admin role. This means he can edit the configuration, read protected nodes (such as passwords) and run privileged commands.

Managing User Roles¶

By default, RPC, notification, configuration, and state access are denied to any users. User roles must be used to set access permissions to Virtual Service Router users.

A user role consists of a set of rules that deny or permit access to a configuration or a state path, an RPC, or a NETCONF notification. A role can be a predefined one (admin or viewer for example) or a custom one.

A user is member of an unordered set of roles. When he makes an operation (commit a configuration, execute an nc-cli command, …), its roles are processed one by one from the lowest priority to the highest, until a rule matching the operation is found. Within a role, deny rules are always processed before permit rules, regardless of the order in which rules were added.

Custom user roles are configurable through the system auth context:

vsr running config# system auth
vsr running auth# role config-except-firewall
vsr running role config-except-firewall#! deny config /vrf/firewall
vsr running role config-except-firewall# permit config / access-permission read-write
vsr running role config-except-firewall# ..
vsr running auth# user barney
vsr running user barney#! role config-except-firewall

In this first example, if user barney edits the / vrf main firewall configuration, the deny rule will be processed first. As the rule matches the requested operation, the processing of roles will end, and the configuration operation will be rejected.

vsr running config# system auth
vsr running auth# role read-config
vsr running role read-config#! priority 1
vsr running role read-config#! permit config / access-permission read
vsr running role read-config# ..
vsr running auth# role edit-interface
vsr running role edit-interface#! priority 2
vsr running role edit-interface#! permit config /vrf/interface/ access-permission read-write
vsr running role edit-interface# permit config /vrf/l3vrf/interface/ access-permission read-write
vsr running role edit-interface# ..
vsr running auth# role edit-config
vsr running role edit-config#! priority 3
vsr running role edit-config#! permit config / access-permission read-write
vsr running role edit-config# ..
vsr running auth# user jane
vsr running user jane#! role edit-config
vsr running user jane# role read-config
vsr running user jane# role edit-interface

In this other example, if user jane commits a configuration with the new vrf main interface loopback d1 interface. The role read-config will be processed first (it has the lowest priority value). As this is a write operation, the rule permit config / access-permission read will not match. So, the next role edit-interface (following in the priority order) will be processed. The permit config /vrf/interface/ access-permission read-write rule will match the operation. So, the processing of roles will end, and the configuration operation will be permitted.

Note

if two roles have the same priority value, the processing order is undefined.

Warning

be careful with deny rules. For example, adding the deny config /vrf[name=\"mgmt\"] rule to the edit-interface role will deny access to the whole VRF mgmt. So, the permit config / rule in the edit-config role will never match for operations needing write access to the VRF mgmt.
rules like permit config /vrf/[something] access-permission read-write don’t permit creating a new VRF. The only way to enable this is to add write permission to the whole VRF configuration:
```
vsr running another-role# permit config /vrf access-permission read-write
```
or, to the whole configuration of a single VRF:
```
vsr running another-role# permit config /vrf[name=\"vrf0\"] access-permission read-write
```

The following predefined roles are also available for users who need to manage notification subscriptions or should not have access to sensitive data:

The nacm-netconf-admin role gives permission to any notification, mandatory RPCs needed to manage notification subscriptions, and configuration/state trees other than config and state ones. This role must be used by users who manage the Virtual Service Router remotely through NETCONF. See the automation documentation for details.
The nacm-deny-protected denies access to any protected data (passwords, secrets, certificates in the configuration/state) and RPCs (like show license, reboot, …). It has no effect if it is not used in addition to another role. Users who can modify the configuration should not be members of this role to avoid working on an incomplete configuration.

Note

admin or viewer user role members cannot be members of another role.
User access permission is based on the RFC 8341. To avoid any unintended side effects, it is not recommended to edit the ietf-netconf-acm:nacm configuration context directly.
The nacm-netconf-admin and nacm-deny-protected roles are always processed first for users members of several roles.

A user role can contain config, state, rpc, and/or notification rules:

The config rules¶

The config rules are used to set read/write access permissions on a specific configuration XPath, and its corresponding state. The following rules enable configuring VXLAN interfaces in any existing VRF and L3VRF. These rules also give access to the state of all VXLAN interfaces.

vsr running role vxlan#! permit config /vrf/interface/vxlan access-permission read-write
vsr running role vxlan# permit config /vrf/l3vrf/interface/vxlan access-permission read-write

The access-permission option enables giving read-only or read/write access to the configuration XPath. This option is available only for permit rules.

It is also possible to permit or deny access to a specific list entry. In the following example, the rule denies access to VXLAN interface configuration in the main VRF. This means that the VXLAN role enables configuring a VXLAN interface in any VRF except the main one.

vsr running role vxlan# deny config /vrf[name=\"main\"]/interface/vxlan
vsr running role vxlan# deny config /vrf[name=\"main\"]/l3vrf/interface/vxlan

A configuration context can usually refer to another context (through a must condition for example). This constraint must be taken into account during the user role configuration. Otherwise, the sub-tree of the configuration can be regarded as invalid because incomplete, or the completion will not work. In this example, the completion of the VXLAN FDB link-interface option will not work as the role doesn’t give access to all other interfaces. This can be fixed by adding rules that give read access to them:

vsr running role vxlan# permit config /vrf/interface access-permission read
vsr running role vxlan# permit config /vrf/l3vrf/interface access-permission read

The state rules¶

The state rules work like config one. The next rule makes available network ports visible in the state:

vsr running role port-state# permit state /network-port

The RPC rules¶

The RPC rules can be used to deny or permit execution of most of the nc-cli commands.

The RPC of a given nc-cli command can be found using the show commands command. This example shows the RPC used to execute show vxlan fdb and flush vlxan fdb nc-cli commands:

vsr> show commands | match vxlan
show vxlan fdb                                 vrouter-vxlan:show-vxlan-fdb
flush vxlan fdb                                vrouter-vxlan:flush-vxlan-fdb

The following example shows 2 rules that give access to VXLAN show and flush FDB RPCs:

vsr running role vxlan# permit rpc vrouter-vxlan:show-vxlan-fdb
vsr running rpc vrouter-vxlan:show-vxlan-fdb# .. ..
vsr running role vxlan# permit rpc vrouter-vxlan:flush-vxlan-fdb
vsr running rpc vrouter-vxlan:flush-vxlan-fdb# .. ..

The * wildcard can be used to match several RPCs in one rule. So, the previous rules can be replaced by this one:

vsr running role vxlan# permit rpc vrouter-vxlan:*
vsr running rpc vrouter-vxlan:*# .. ..

It is also possible to permit or deny access to a specific VRF or L3VRF.

This example denies execution of the show vxlan fdb and the flush vxlan fdb RPCs when executed in the main VRF. So, in addition to the previous rule, vxlan user members can execute the show vxlan fdb RPCs in any VRF except main:

vsr running role vxlan# deny rpc vrouter-vxlan:* vrf main

The * wildcard can be used to match several VRF or L3VRF at once. This example augments the permit rpc * rule to permit only L3VRFs beginning with red in any VRF. In addition to the previous rule, vxlan user members can execute vxlan RPCs only in L3VRFs beginning by red in any VRF except main:

vsr running role vxlan# permit rpc vrouter-vxlan:* vrf * l3vrf red*

Note

Mandatory RPCs needed to make nc-cli work are automatically added to the user role configuration if they are not explicitly configured.

The notification rules¶

The NETCONF notification mechanism can be used to be informed of many system changes (a service or interface state changes for example). The remote subscription documentation explains how this works.

The notification rules enable setting access permission to them. This works like rpc one. This example shows a user role that enables subscribing to alarm notifications:

vsr running role alarm-notif# permit rpc notifications:create-subscription
vsr running rpc notifications:create-subscription# .. ..
vsr running role alarm-notif# permit rpc ietf-subscribed-notifications:kill-subscription
vsr running rpc ietf-subscribed-notifications:kill-subscription# .. ..
vsr running role alarm-notif# permit notification ietf-alarms:alarm-notification

User role examples¶

This first example shows the configuration of a user that can configure the firewall in any VRF except the mgmt one (for which the whole access is denied).

This first role is used to deny access to the mgmt VRF. As it has the highest priority, any user member of this role will not be able to configure or see the state of the mgmt VRF, or to execute any RPC in this VRF:

vsr running auth# role deny-mgmt-vrf
vsr running role deny-mgmt-vrf#! priority 0
vsr running role deny-mgmt-vrf#! deny config /vrf[name=\"mgmt\"]
vsr running role deny-mgmt-vrf# deny rpc * vrf mgmt
vsr running role deny-mgmt-vrf# ..

This second group gives access permission to configure the firewall in any VRF. To enable configuring rules with address or network groups, at least, read access permission to the /vrf/group configuration context must be set. Otherwise, a firewall configuration using address or network groups will be regarded as invalid.

vsr running auth# role firewall-manager
vsr running role firewall-manager#! permit config /vrf/firewall/ipv4 access-permission read-write
vsr running role firewall-manager# permit config /vrf/firewall/ipv6 access-permission read-write
vsr running role firewall-manager# permit config /vrf/group access-permission read
vsr running role firewall-manager# permit rpc vrouter-firewall*:*
vsr running rpc vrouter-firewall*:*# .. ..
vsr running role firewall-manager# ..

Then here is the configuration for a user that can manage the firewall:

vsr running auth# user barney
vsr running user barney#! role deny-mgmt-vrf
vsr running user barney# role firewall-manager
vsr running user barney# password
Enter value for password> **********
Confirm value for password> **********
vsr running user barney# ..
vsr running auth# commit
Configuration committed.

The same configuration can be made using this NETCONF XML configuration:

vsr running user john# show config xml absolute
<config xmlns="urn:6wind:vrouter">
  <system xmlns="urn:6wind:vrouter/system">
    <auth xmlns="urn:6wind:vrouter/system/auth">
      <role>
        <name>deny-mgmt-vrf</name>
        <priority>0</priority>
        <deny>
          <config>
            <path>/vrf[name="mgmt"]</path>
          </config>
          <rpc>
            <name>*</name>
            <vrf>
              <name>mgmt</name>
            </vrf>
          </rpc>
        </deny>
      </role>
      <role>
        <name>firewall-manager</name>
        <priority>255</priority>
        <permit>
          <config>
            <path>/vrf/firewall/ipv4</path>
            <access-permission>read-write</access-permission>
          </config>
          <config>
            <path>/vrf/firewall/ipv6</path>
            <access-permission>read-write</access-permission>
          </config>
          <config>
            <path>/vrf/group</path>
            <access-permission>read</access-permission>
          </config>
          <rpc>
            <name>vrouter-firewall*:*</name>
          </rpc>
        </permit>
      </role>
      <user>
        <name>barney</name>
        <role>deny-mgmt-vrf</role>
        <role>firewall-manager</role>
      </user>
      <root-user-enabled>true</root-user-enabled>
      <default-users-enabled xmlns="urn:6wind:vrouter/embedded">true</default-users-enabled>
    </auth>
  </system>
</config>

This second example configures an operator role that sets access permission to all RPCs, notifications, and read-only permission to the whole configuration and state. This is like the viewer role but this one can show protected data and enable executing protected RPCs:

vsr running auth# role advanced-viewer
vsr running role advanced-viewer#! permit config / access-permission read
vsr running role advanced-viewer# permit rpc *
vsr running rpc *# .. ..
vsr running role advanced-viewer# permit notification *
vsr running role advanced-viewer# ..

Note

To have the same rights as the default viewer role, the user should also be member of the nacm-deny-protected role.

This last example configures an admin-like role. This is the same as the previous one, except that the role also gives write permission to the configuration:

vsr running auth# role cli-admin
vsr running role cli-admin#! permit config / access-permission read-write
vsr running role cli-admin# permit rpc *
vsr running rpc *# .. ..
vsr running role cli-admin# permit notification *
vsr running role cli-admin# ..

Note

To have the same rights as the default admin role, the user should also be member of the nacm-netconf-admin role.

Displaying user permissions¶

The permissions of a given user can be displayed with the show user permission command:

vsr> show user permissions barney
barney user roles: deny-mgmt-vrf firewall-manager

rule                                                   action
====                                                   ======
config /vrf[name="mgmt"]                               deny
config /vrf/firewall/ipv4 access-permission read-write permit
config /vrf/firewall/ipv6 access-permission read-write permit
config /vrf/group access-permission read               permit

state /vrf[name="mgmt"]                                deny
state /vrf/firewall/ipv4                               permit
state /vrf/firewall/ipv6                               permit
state /vrf/group                                       permit

rpc * vrf mgmt                                         deny
rpc vrouter-commands:convert-to-text                   permit
rpc vrouter-commands:get-command-status                permit
rpc vrouter-commands:refresh-command                   permit
rpc vrouter-commands:stop-command                      permit
rpc vrouter-commands:get-completion                    permit
rpc vrouter-commands:get-features                      permit
rpc vrouter-commit-history:set-next-commit-description permit
rpc ietf-netconf:lock                                  permit
rpc ietf-netconf:unlock                                permit
rpc ietf-netconf:edit-config                           permit
rpc vrouter-firewall*:*                                permit

Note

Rules set by predefined user role are not displayed by this command.

Configuring SSH Authorized Keys¶

SSH authentication can be used to login to Virtual Service Router without a password.

This requires to configure one or more authorized-key.

Generating a key pair¶

First, you need to generate a key pair on a remote machine.

user@my-laptop:~$ ssh-keygen -t ecdsa
Generating public/private ecdsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_ecdsa):
Enter passphrase (empty for no passphrase): ********
Enter same passphrase again: ********
Your identification has been saved in /home/user/.ssh/id_ecdsa.
Your public key has been saved in /home/user/.ssh/id_ecdsa.pub.
The key fingerprint is:
SHA256:UrMHdqPxmoeV8DNYRtL0Il5cWAFfzZn7PHy4j2enH5A robobuild@ubuntu1604es
The key's randomart image is:
+---[ECDSA 256]---+
|        .o+++..oo|
|         +o+ . oo|
|        O O o   .|
|       + ^ +  .. |
|      . S O  E.o.|
|       . * o  oo+|
|        + .    oo|
|         .    ..=|
|              o*+|
+----[SHA256]-----+

Configuring an `authorized-key` for CLI users¶

Copy the public key file contents into the configuration:

user@my-laptop:~$ cat ~/.ssh/id_ecdsa.pub
ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBH2hK42JHtTYU1XRw2Zu4xCriM7CIXBl19p1/1qkapobkS6yCnwauqTEveBw1GOjwuTADvqQVozBoaLbY3KGmsI= user@my-laptop

vsr running user john# authorized-key "ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBH2hK42JHtTYU1XRw2Zu4xCriM7CIXBl19p1/1qkapobkS6yCnwauqTEveBw1GOjwuTADvqQVozBoaLbY3KGmsI= user@my-laptop"
vsr running user john# commit
Configuration applied.

Warning

NEVER copy the private key contents. Only the PUBLIC key.

Configuring an `authorized-key` for `root` user¶

This is done from the Linux shell. Copy the public key file contents into the /root/.ssh/authorized_keys file:

user@my-laptop:~$ cat ~/.ssh/id_ecdsa.pub
ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBH2hK42JHtTYU1XRw2Zu4xCriM7CIXBl19p1/1qkapobkS6yCnwauqTEveBw1GOjwuTADvqQVozBoaLbY3KGmsI= user@my-laptop

root@vsr:~# cat >> /root/.ssh/authorized_keys
ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBH2hK42JHtTYU1XRw2Zu4xCriM7CIXBl19p1/1qkapobkS6yCnwauqTEveBw1GOjwuTADvqQVozBoaLbY3KGmsI= user@my-laptop
<Ctrl+D>
root@vsr:~# chmod 600 /root/.ssh/authorized_keys

Checking the connection¶

After which you may check that the remote authentication works without a password:

user@my-laptop:~$ ssh -i ~/.ssh/id_ecdsa john@vsr
The authenticity of host 'vsr (10.0.0.58)' can't be established.
ECDSA key fingerprint is SHA256:nNerPB16BKwHmcex5IVKS7YMVt4VuaVavH3LId7uI6Q.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'vsr,10.0.0.58' (ECDSA) to the list of known hosts.
Enter passphrase for key '/home/user/.ssh/id_ecdsa': ********
Welcome to Virtual Service Router - 3.9

vsr>

Note

If you did set a passphrase on your private key, you will need to enter it.

Managing user login¶

There are two ways to monitor the users login events in Virtual Service Router.

Using logs¶

The authpriv log facility contains the logs about failed and successful logins and logouts. The following logs show a failed login by the admin user using ssh, then a successful one, and a logout.

vsr> show log facility authpriv
Dec 06 18:07:50 ubuntu2004 sshd[59303]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=127.0.0.1  user=admin
Dec 06 18:07:59 ubuntu2004 sshd[59303]: pam_unix(sshd:session): session opened for user admin by (uid=0)
Dec 06 18:08:09 ubuntu2004 sshd[59303]: pam_unix(sshd:session): session closed for user admin

Using `show logins`¶

The show logins rpc displays the same information as the logs, but with filters.

The following command shows the last three login events for the admin user, limited to the events since 2022-12-06 18:07:52.

ubuntu2004> show logins max-lines 3 user admin since "2022-12-06 18:07:52"
user                 id  source           session start        session end          status
==================== === ================ ==================== ==================== ========
admin                4   192.168.1.1      2022-12-06 18:10:38  still logged in      success
admin                6   192.168.1.1      2022-12-06 18:12:21  still logged in      success
admin                -   192.168.1.1      2022-12-06 18:07:59  2022-12-06 18:08:09  success
admin                -   192.168.1.1      2022-12-06 18:07:52  2022-12-06 18:07:52  failure

Users¶

Overview¶

Changing Passwords¶

CLI users¶

root user¶

Creating Users¶

Managing User Roles¶

The config rules¶

The state rules¶

The RPC rules¶

The notification rules¶

User role examples¶

Displaying user permissions¶

Configuring SSH Authorized Keys¶

Generating a key pair¶

Configuring an authorized-key for CLI users¶

Configuring an authorized-key for root user¶

Checking the connection¶

Managing user login¶

Using logs¶

Using show logins¶

Terminating a login session¶

`root` user¶

Configuring an `authorized-key` for CLI users¶

Configuring an `authorized-key` for `root` user¶

Using `show logins`¶