Overview¶
Two user roles are available by default:
viewerfor use in operational mode where the configuration cannot bechanged, only commands to troubleshoot or monitor are available.This is the default role for new users.
adminfor use in configuration mode, with full access.
It is also possible to configure custom user roles. See ManagingUser Roles.
Three user accounts are provided by default:
Account | Defaultpassword | Description |
|---|---|---|
|
| The standard account for configuration.It has the |
|
| A restricted account for monitoring purposes.It has the |
|
| Provides the ability to log into the Linuxsubsystem as superuser. Note that any configurationor customization of the Virtual Service Router in this mode is outof the support scope, may break the system, and willbe lost after an update. |
Warning
For security reasons, it is recommended to change the defaultpasswords 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 permissionsto edit the configuration and run privileged commands.
The viewer acccount has the viewer role, which means that it haspermissions to view the configuration but not to edit it and run standardcommands.
Warning
For obvious security reasons, you MUST change the passwords of theseusers.
You may even want to completely disable the default admin and viewerusers, by setting default-users-enabled to false:
vsr running config# system auth default-users-enabled falsevsr running config# commitConfiguration applied.
In this case, you must configure a user with the admin role, else you willlose 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 adminvsr running user admin#! role adminvsr running user admin# passwordEnter value for password> **********vsr running user admin# commitConfiguration applied.
For security reasons, the password is not stored in clear-text in theconfiguration. A hash is stored instead.
vsr running user admin# show configuser admin role admin password $5$Ndx/QlMS5Anp7LTq$Lws2OmAm0SO.cBmPBGtdpwnfdAM4hDM4AdSO4ncXjS/
It is also possible to directly set the password as a hashed value. Togenerate a hashed password on a Linux machine, use mkpasswd, which isprovided in the whois package:
root@host:~# mkpasswd -m SHA-256Password: **********$5$Ndx/QlMS5Anp7LTq$Lws2OmAm0SO.cBmPBGtdpwnfdAM4hDM4AdSO4ncXjS/
root user¶
Changing the password for the root user is done through the Linux shell:
root@vsr:~# passwdEnter 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 anew user with the following commands:
vsr running user admin# ..vsr running auth# user johnvsr running user john# role adminvsr running user john# passwordEnter value for password> **********vsr running user john# commitConfiguration 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 stateuser 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 toany 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 aconfiguration or a state path, an RPC, or a NETCONF notification. A rolecan 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 areprocessed one by one from the lowest priority to the highest, until a rulematching the operation is found. Within a role, deny rules are alwaysprocessed before permit rules, regardless of the order in which rules wereadded.
Custom user roles are configurable through the system auth context:
vsr running config# system authvsr running auth# role config-except-firewallvsr running role config-except-firewall#! deny config /vrf/firewallvsr running role config-except-firewall# permit config / access-permission read-writevsr running role config-except-firewall# ..vsr running auth# user barneyvsr running user barney#! role config-except-firewall
In this first example, if user barney edits the / vrf main firewallconfiguration, the deny rule will be processed first. As the rule matches therequested operation, the processing of roles will end, and the configurationoperation will be rejected.
vsr running config# system authvsr running auth# role read-configvsr running role read-config#! priority 1vsr running role read-config#! permit config / access-permission readvsr running role read-config# ..vsr running auth# role edit-interfacevsr running role edit-interface#! priority 2vsr running role edit-interface#! permit config /vrf/interface/ access-permission read-writevsr running role edit-interface# permit config /vrf/l3vrf/interface/ access-permission read-writevsr running role edit-interface# ..vsr running auth# role edit-configvsr running role edit-config#! priority 3vsr running role edit-config#! permit config / access-permission read-writevsr running role edit-config# ..vsr running auth# user janevsr running user jane#! role edit-configvsr running user jane# role read-configvsr running user jane# role edit-interface
In this other example, if user jane commits a configuration with the new vrfmain interface loopback d1 interface. The role read-config will be processedfirst (it has the lowest priority value). As this is a write operation, therule permit config / access-permission read will not match. So, the next roleedit-interface (following in the priority order) will be processed. Thepermit config /vrf/interface/ access-permission read-write rule will matchthe operation. So, the processing of roles will end, and the configurationoperation will be permitted.
Note
if two roles have the same
priorityvalue, the processing order isundefined.
Warning
be careful with
denyrules. For example, adding thedeny config/vrf[name=\"mgmt\"]rule to theedit-interfacerole will deny accessto the whole VRFmgmt. So, thepermit config /rule in theedit-configrole will never match for operations needing write access tothe VRFmgmt.rules like
permit config /vrf/[something] access-permission read-writedon’t permit creating a new VRF. The only way to enable this is to addwrite permission to the whole VRF configuration:vsr running another-role# permit config /vrf access-permission read-writeor, 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 managenotification subscriptions or should not have access to sensitive data:
The
nacm-netconf-adminrole gives permission to any notification, mandatoryRPCs needed to manage notification subscriptions, and configuration/statetrees other thanconfigandstateones. This role must be used by userswho manage the Virtual Service Router remotely through NETCONF. See the automationdocumentation for details.The
nacm-deny-protecteddenies access to any protected data (passwords,secrets, certificates in the configuration/state) and RPCs (like showlicense, reboot, …). It has no effect if it is not used in addition toanother role. Users who can modify the configuration should not be members ofthis role to avoid working on an incomplete configuration.
Note
adminorvieweruser role members cannot be members of another role.User access permission is based on the RFC 8341. To avoid anyunintended side effects, it is not recommended to edit the
ietf-netconf-acm:nacmconfiguration context directly.The
nacm-netconf-adminandnacm-deny-protectedroles are alwaysprocessed 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 specificconfiguration XPath, and its corresponding state. The following rules enableconfiguring VXLAN interfaces in any existing VRF and L3VRF. These rulesalso give access to the state of all VXLAN interfaces.
vsr running role vxlan#! permit config /vrf/interface/vxlan access-permission read-writevsr 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 tothe configuration XPath. This option is available only for permit rules.
It is also possible to permit or deny access to a specific list entry. Inthe following example, the rule denies access to VXLAN interfaceconfiguration in the main VRF. This means that the VXLAN role enablesconfiguring a VXLAN interface in any VRF except the main one.
vsr running role vxlan# deny config /vrf[name=\"main\"]/interface/vxlanvsr running role vxlan# deny config /vrf[name=\"main\"]/l3vrf/interface/vxlan
A configuration context can usually refer to another context (through a mustcondition for example). This constraint must be taken into account during theuser role configuration. Otherwise, the sub-tree of the configuration can beregarded as invalid because incomplete, or the completion will not work. Inthis example, the completion of the VXLAN FDB link-interface option willnot work as the role doesn’t give access to all other interfaces. This can befixed by adding rules that give read access to them:
vsr running role vxlan# permit config /vrf/interface access-permission readvsr 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 networkports visible in the state:
vsr running role port-state# permit state /network-portThe RPC rules¶
The RPC rules can be used to deny or permit execution of most of the nc-clicommands.
The RPC of a given nc-cli command can be found using the show commandscommand. This example shows the RPC used to execute show vxlan fdb andflush vlxan fdb nc-cli commands:
vsr> show commands | match vxlanshow vxlan fdb vrouter-vxlan:show-vxlan-fdbflush vxlan fdb vrouter-vxlan:flush-vxlan-fdb
The following example shows 2 rules that give access to VXLAN show andflush FDB RPCs:
vsr running role vxlan# permit rpc vrouter-vxlan:show-vxlan-fdbvsr running rpc vrouter-vxlan:show-vxlan-fdb# .. ..vsr running role vxlan# permit rpc vrouter-vxlan:flush-vxlan-fdbvsr running rpc vrouter-vxlan:flush-vxlan-fdb# .. ..
The * wildcard can be used to match several RPCs in one rule. So, theprevious 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 orL3VRF.
This example denies execution of the show vxlan fdb and the flush vxlan fdbRPCs when executed in the main VRF. So, in addition to the previousrule, vxlan user members can execute the show vxlan fdb RPCs in anyVRF except main:
vsr running role vxlan# deny rpc vrouter-vxlan:* vrf mainThe * wildcard can be used to match several VRF or L3VRF at once. Thisexample augments the permit rpc * rule to permit only L3VRFs beginningwith red in any VRF. In addition to the previous rule, vxlan user memberscan execute vxlan RPCs only in L3VRFs beginning by red in any VRFexcept 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 theuser role configuration if they are not explicitly configured.
The notification rules¶
The NETCONF notification mechanism can be used to be informed of many systemchanges (a service or interface state changes for example). The remotesubscription documentationexplains how this works.
The notification rules enable setting access permission to them. This workslike rpc one. This example shows a user role that enables subscribing toalarm notifications:
vsr running role alarm-notif# permit rpc notifications:create-subscriptionvsr running rpc notifications:create-subscription# .. ..vsr running role alarm-notif# permit rpc ietf-subscribed-notifications:kill-subscriptionvsr 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 thefirewall in any VRF except the mgmt one (for which the whole access isdenied).
This first role is used to deny access to the mgmt VRF. As it has thehighest priority, any user member of this role will not be able to configure orsee the state of the mgmt VRF, or to execute any RPC in this VRF:
vsr running auth# role deny-mgmt-vrfvsr running role deny-mgmt-vrf#! priority 0vsr running role deny-mgmt-vrf#! deny config /vrf[name=\"mgmt\"]vsr running role deny-mgmt-vrf# deny rpc * vrf mgmtvsr running role deny-mgmt-vrf# ..
This second group gives access permission to configure the firewall in anyVRF. 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 beregarded as invalid.
vsr running auth# role firewall-managervsr running role firewall-manager#! permit config /vrf/firewall/ipv4 access-permission read-writevsr running role firewall-manager# permit config /vrf/firewall/ipv6 access-permission read-writevsr running role firewall-manager# permit config /vrf/group access-permission readvsr 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 barneyvsr running user barney#! role deny-mgmt-vrfvsr running user barney# role firewall-managervsr running user barney# passwordEnter value for password> **********Confirm value for password> **********vsr running user barney# ..vsr running auth# commitConfiguration 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 toall RPCs, notifications, and read-only permission to the whole configurationand state. This is like the viewer role but this one can show protecteddata and enable executing protected RPCs:
vsr running auth# role advanced-viewervsr running role advanced-viewer#! permit config / access-permission readvsr 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 alsobe member of the nacm-deny-protected role.
This last example configures an admin-like role. This is the same as theprevious one, except that the role also gives write permission to theconfiguration:
vsr running auth# role cli-adminvsr running role cli-admin#! permit config / access-permission read-writevsr 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 bemember of the nacm-netconf-admin role.
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 ecdsaGenerating 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@ubuntu1604esThe 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.pubecdsa-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# commitConfiguration 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.pubecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBH2hK42JHtTYU1XRw2Zu4xCriM7CIXBl19p1/1qkapobkS6yCnwauqTEveBw1GOjwuTADvqQVozBoaLbY3KGmsI= user@my-laptoproot@vsr:~# cat >> /root/.ssh/authorized_keysecdsa-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 apassword:
user@my-laptop:~$ ssh -i ~/.ssh/id_ecdsa john@vsrThe 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)? yesWarning: 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.8vsr>
Note
If you did set a passphrase on your private key, you will need to enter it.
See also
The command reference for details.
Monitoring user login events¶
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 loginsand logouts. The following logs show a failed login by the admin user usingssh, then a successful one, and a logout.
vsr> show log facility authprivDec 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=adminDec 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 source session start session end status==================== ================ ==================== ==================== ========admin 192.168.1.1 2022-12-06 18:10:38 still logged in successadmin 192.168.1.1 2022-12-06 18:07:59 2022-12-06 18:08:09 successadmin 192.168.1.1 2022-12-06 18:07:52 2022-12-06 18:07:52 failure
See also
The command reference for details.
