Local users on Junos are configured under the system login hierarchy.
To configure centrally managed user accounts, you can use RADIUS or TACACS.
Users And Classes
Users are the individual user accounts. Each account is assigned to a class.
The classes act like user groups, specifying what permissions a user has.
There are four pre-existing classes defined. You can define additional classes to suit your needs.
[edit system login]
lab@vMX-1# set user user1 class ?
Possible completions:
<class> Login class
operator permissions [ clear network reset trace view ]
read-only permissions [ view ]
super-user permissions [ all ]
unauthorized permissions [ none ]
Note that the class ‘super-user’ can also be written as ‘superuser’.
Creating A New User
To create a new user you must specify the username and the class they belong to. The command is:
set system login user <username> class <class-name> authentication plain-text-password
You will then be prompted to enter a password. This is demonstrated below, creating user3 and assigning them the super-user class.
When setting a user password with ‘authentication plain-text-password’ you cannot put the actual password on the end of the command, you must hit the enter or return key, and put the password in at the prompt.
[edit]
lab@vMX-1# set system login user user3 class super-user authentication plain-text-password
New password:
Retype new password:
[edit]
lab@vMX-1# show | compare
[edit system login]
+ user user3 {
+ class super-user;
+ authentication {
+ encrypted-password "PASSWORD HASH REMOVED"; ## SECRET-DATA
+ }
+ }
[edit]
lab@vMX-1#
A common misunderstanding with the authentication portion of the command is what ‘plain-text-authentication’ or ‘encrypted-password’ means. In Junos, all passwords are encrypted in the configuration file. The plain text or encrypted password specifies what format the password will be entered in. If you are typing the password in manually then ‘plain-text-password’ should be used. If you are entering the hash of a password, then ‘encrypted-password’ should be used.
Local users can also authenticate using SSH keys.
Changing Or Resetting A User’s Password
To change or reset a user’s password run the following command.
set system login user <username> authentication plain-text-password
You will be prompted to enter a new password. This will take effect after you commit the change. An example is shown below.
[edit]
lab@vMX-1# set system login user user3 authentication plain-text-password
New password:
Retype new password:
[edit]
lab@vMX-1# show | compare
[edit system login user user3 authentication]
- encrypted-password "OLD PASSWORD HASH"; ## SECRET-DATA
+ encrypted-password "NEW PASSWORD HASH"; ## SECRET-DATA
[edit]
lab@vMX-1#
Local User Password Displayed in Clear Text
Sometimes it will appear that Junos is not encrypting a user password, it looks like this in the configuration.
[edit]
lab@vMX-1# show system login user user3
uid 2006;
class read-only;
authentication {
encrypted-password My-Shiny-Password; ## SECRET-DATA
}
[edit]
lab@vMX-1#
Can you spot the mistake? The plain text password was entered as an ‘encrypted-password’. Because Junos expects that to be supplied as a hash, it puts it in the config exactly as typed.
Note that the user will not be able to log in with that password, as the password they supply will be hashed, which will not match ‘My-Shiny-Password’.
Creating Another Root User (Super-User) Account
The root account has a class of ‘super-user’. To create an additional root account, or an account with similar permissions in the CLI, simply add a user and give them the class of ‘super-user’.
It is a good idea to create at least one additional super-user as an alternative to the root account.
How To Delete Or Remove A User Account
To delete a user, you simply delete their account and commit the change.
[edit]
lab@vMX-1# show system login user user3
uid 2003;
class my-new-class;
authentication {
encrypted-password "HASH REMOVED"; ## SECRET-DATA
}
[edit]
lab@vMX-1# delete system login user user3
[edit]
lab@vMX-1# show |compare
[edit system login]
- user user3 {
- uid 2003;
- class my-new-class;
- authentication {
- encrypted-password "HASH REMOVED"; ## SECRET-DATA
- }
- }
[edit]
lab@vMX-1# commit
commit complete
[edit]
lab@vMX-1#
Creating A Custom Class
You are not restricted to using the pre-defined user classes. You can create custom ones to meet your own needs.
The possible permissions you can give your new class are shown below.
[edit]
lab@vMX-1# set system login class my-new-class permissions ?
Possible completions:
[ Open a set of values
access Can view access configuration
access-control Can modify access configuration
admin Can view user accounts
admin-control Can modify user accounts
all All permission bits turned on
clear Can clear learned network info
configure Can enter configuration mode
control Can modify any config
field Can use field debug commands
firewall Can view firewall configuration
firewall-control Can modify firewall configuration
floppy Can read and write the floppy
flow-tap Can view flow-tap configuration
flow-tap-control Can modify flow-tap configuration
flow-tap-operation Can tap flows
idp-profiler-operation Can Profiler data
interface Can view interface configuration
interface-control Can modify interface configuration
maintenance Can become the super-user
network Can access the network
pgcp-session-mirroring Can view pgcp session mirroring configuration
pgcp-session-mirroring-control Can modify pgcp session mirroring configuration
reset Can reset/restart interfaces and daemons
rollback Can rollback to previous configurations
routing Can view routing configuration
routing-control Can modify routing configuration
secret Can view secret statements
secret-control Can modify secret statements
security Can view security configuration
security-control Can modify security configuration
shell Can start a local shell
snmp Can view SNMP configuration
snmp-control Can modify SNMP configuration
storage Can view fibre channel storage protocol configuration
storage-control Can modify fibre channel storage protocol configuration
system Can view system configuration
system-control Can modify system configuration
trace Can view trace file settings
trace-control Can modify trace file settings
unified-edge Can view unified edge configuration
unified-edge-control Can modify unified edge configuration
view Can view current values and statistics
view-configuration Can view all configuration (not including secrets)
[edit]
lab@vMX-1#
In the next output, we will create a new class and apply it to user3. As you will see, the choice of what permissions to give a class can take some trial and error to get right.
[edit]
lab@vMX-1# set system login class my-new-class permissions firewall
[edit]
lab@vMX-1# set system login class my-new-class permissions interface
[edit]
lab@vMX-1# set system login class my-new-class permissions routing
[edit]
lab@vMX-1# set system login user user3 class my-new-class
[edit]
lab@vMX-1# show | compare
[edit system login]
+ class my-new-class {
+ permissions [ firewall interface routing ];
+ }
[edit system login user user3]
- class super-user;
+ class my-new-class;
[edit]
lab@vMX-1#
If we now log in as user3, we can see that the new class doesn’t allow us to do very much at all, we can’t even run a show command.
user3@vMX-1> ?
Possible completions:
file Perform file operations
help Provide help information
load Load information from file
op Invoke an operation script
quit Exit the management session
request Make system-level requests
save Save information to file
scp Copy files via ssh
set Set CLI properties, date/time, craft interface message
start Start shell
test Perform diagnostic debugging
user3@vMX-1> show
^
unknown command.
user3@vMX-1> show?
No valid completions
user3@vMX-1>
After adding the ‘view’ permission to my-new-class and logging user3 out and back in again, we can now run the show command. We can also check what permissions our user has with a ‘show cli authorization’.
user3@vMX-1> sho?
Possible completions:
show Show system information
user3@vMX-1> show cli authorization
Current user: 'user3 ' class 'my-new-class'
Permissions:
firewall -- Can view firewall configuration
interface -- Can view interface configuration
routing -- Can view routing configuration
view -- Can view current values and statistics
Individual command authorization:
Allow regular expression: none
Deny regular expression: none
Allow configuration regular expression: none
Deny configuration regular expression: none
user3@vMX-1>
Allowing Or Denying Commands
The permissions system isn’t always quite as granular as you may like. Junos also offers the ability to add or restrict what individual commands a user can run, or what configuration they can configure.
This is done via the user class, with the following options possible:
- allow-commands Regular expression for commands to allow explicitly
- allow-commands-regexps Object path regular expressions to allow commands
- allow-configuration Regular expression for configure to allow explicitly
- allow-configuration-regexps Object path regular expressions to allow
- deny-commands Regular expression for commands to deny explicitly
- deny-commands-regexps Object path regular expressions to deny commands
- deny-configuration Regular expression for configure to deny explicitly
- deny-configuration-regexps Object path regular expressions to deny
The deny options take precedence over the allow ones.
The allow/deny versions cannot be used with the allow/deny regexp version in the same class.
The user3 account is currently set to the my-new-class which only has the view permission. It can’t run the ping or show interfaces description commands but can run the show route command.
user3@vMX-1> show cli authorization
Current user: 'user3 ' class 'my-new-class'
Permissions:
view -- Can view current values and statistics
Individual command authorization:
Allow regular expression: none
Deny regular expression: none
Allow configuration regular expression: none
Deny configuration regular expression: none
user3@vMX-1> ping
^
unknown command.
user3@vMX-1> show interfaces description
error: device description not found
user3@vMX-1> show route
inet.0: 23 destinations, 23 routes (23 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
OUTPUT OMITTED FOR BREVITY
We can set the allow and deny commands as follows.
[edit]
lab@vMX-1# show system login class my-new-class
permissions view;
allow-commands "(ping *)|(show interfaces description)";
deny-commands "show route";
[edit]
lab@vMX-1#
User3 can now run the ping and show interfaces description command, but can’t run a show route.
user3@vMX-1> show cli authorization
Current user: 'user3 ' class 'my-new-class'
Permissions:
view -- Can view current values and statistics
Individual command authorization:
Allow regular expression: (ping *)|(show interfaces description)
Deny regular expression: show route
Allow configuration regular expression: none
Deny configuration regular expression: none
user3@vMX-1> ping
^
missing argument.
user3@vMX-1> show interfaces descriptions
Interface Admin Link Description
ge-0/0/1 up up Awesome Description Here
ge-0/0/2 up up Ge-0/0/2 Description Here
user3@vMX-1> show rou
^
syntax error.
user3@vMX-1> show route
^
syntax error, expecting <command>.
user3@vMX-1> show r?
Possible completions:
remote-device-management Show remote device management information
rip Show Routing Information Protocol information
ripng Show Routing Information Protocol for IPv6 information
rsvp Show Resource Reservation Protocol information
user3@vMX-1>
Junos Password Complexity
The default complexity for user passwords is:
Format: sha512, password hashes begin with $6$
Maximum Length: For plain text passwords Junos is no max length and Junos-FIPS is 20.
Minimum Changes: For Junos, the default is 1, for Junos-FIPS it is 3.
Minimum Length: For plain text passwords Junos is 6 and Junos-FIPS is 10.
The minimum changes setting combines with the change type, which can either be character sets or transitions between character sets. The character sets are upper case, lower case, numeric, punctuation, and other special characters.
So with the default of change-type being character sets and minimum changes being 1, the password simply has to make use of two different character sets. For example, lowercase and numeric.
To change the complexity requirements for user passwords, you can use the settings under system login password.
[edit]
lab@vMX-1# set system login password ?
Possible completions:
+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except Don't inherit configuration data from these groups
change-type Password change type
format Encryption method to use for password
maximum-length Maximum password length for all users (20..128)
maximum-lifetime Maximum password lifetime in days (30..365)
minimum-changes Minimum number of changes in password
minimum-character-changes Minimum number of character changes between old and new passwords (4..15)
minimum-length Minimum password length for all users (6..20)
minimum-lifetime Minimum password lifetime in days (1..30)
minimum-lower-cases Minimum number of lower-case class characters in password (1..128)
minimum-numerics Minimum number of numeric class characters in password (1..128)
minimum-punctuations Minimum number of punctuation class characters in password (1..128)
minimum-reuse Minimum number of old passwords which should not be same as the new password (1..20)
minimum-upper-cases Minimum number of upper-case class characters in password (1..128)
[edit]
lab@vMX-1#
Something to keep in mind when changing password complexity is that the change won’t take effect until after it has been committed. So if you change the complexity requirements and then try to change a user password without a commit in between the two steps, the password will have to comply with the existing requirements.
In this example, we can change the requirements to a minimum length of 10 and 3 changes, which forces the use of 4 character sets.
[edit]
lab@vMX-1# show system login password
minimum-length 10;
minimum-changes 3;
[edit]
lab@vMX-1#
What happens when we try to set a new password for user3 after committing the above change?
[edit]
lab@vMX-1# set system login user user3 authentication plain-text-password
New password: pass1@;
error: minimum password length is 10
error: require 3 changes of case, digits or punctuation
[edit]
lab@vMX-1#set system login user user3 authentication plain-text-password
New password: passwordishere
error: require 3 changes of case, digits or punctuation
[edit]
lab@vMX-1# set system login user user3 authentication plain-text-password
New password: PASSword12.@
Retype new password: PASSword12.@
[edit]
lab@vMX-1#
Why Does This Account Not Have A Password
You may occasionally see a user account with no password set, similar to the ‘remote’ and ‘operators’ accounts in the following output. These are typically role accounts used with RADIUS to authenticate users centrally, rather than having individual user accounts on all the devices across the network.
[edit]
lab@vMX-1# show system login
class my-new-class {
permissions [ firewall interface routing view ];
}
user operators {
uid 2004;
class operator;
}
user remote {
uid 2005;
class read-only;
}
user user1 {
uid 2001;
class super-user;
authentication {
encrypted-password "HASH REMOVED"; ## SECRET-DATA
}
}
user user2 {
uid 2002;
class read-only;
authentication {
encrypted-password "HASH REMOVED"; ## SECRET-DATA
}
}
[edit]
lab@vMX-1#
The lack of an authentication setting with the role accounts doesn’t mean they have a blank password. If I try to log in via ssh I get the following.
eve@lab1:~$ ssh [email protected]
([email protected]) Password:
([email protected]) Password:
([email protected]) Password:
Received disconnect from 10.0.0.21 port 22:2: Too many password failures for remote
Disconnected from 10.0.0.21 port 22
eve@lab1:~$
Checking the log files on the router also shows failed attempts.
lab@vMX-1> show log messages | last 10 | match sshd
Jan 3 10:53:24 vMX-1 sshd: SSHD_LOGIN_FAILED: Login failed for user 'remote' from host '10.0.0.1'
Jan 3 10:53:30 vMX-1 sshd[14213]: error: PAM: authentication error for remote from 10.0.0.1
Jan 3 10:53:30 vMX-1 sshd: SSHD_LOGIN_FAILED: Login failed for user 'remote' from host '10.0.0.1'
Jan 3 10:53:46 vMX-1 sshd: SSHD_LOGIN_ATTEMPTS_THRESHOLD: Threshold for unsuccessful authentication attempts (3) reached by user 'remote'
Jan 3 10:53:46 vMX-1 sshd[14214]: Disconnecting authenticating user remote 10.0.0.1 port 57206: Too many password failures for remote
Jan 3 10:53:46 vMX-1 sshd[14213]: Disconnecting authenticating user remote 10.0.0.1 port 57206: Too many password failures for remote [preauth]
Jan 3 10:53:46 vMX-1 inetd[8660]: /usr/sbin/sshd[14213]: exited, status 255