Setting Up Login Accounts on the Router

Problem

You want a number of people to be able to work on the router to monitor and configure it.

Solution

Set up a login account for each person who is allowed to log in to the router:

	[edit system login]
	aviva@router1# set user sage class operator
	aviva@router1# set user sage full-name "sage david"
	aviva@router1# set user sage uid 1991
	aviva@router1# set user sage authentication plain-text-password
	New password:
	Retype new password:

 

Discussion

For each user who you want to log in to the router, create a login account, providing information about the user that is similar to what you set for Unix accounts. The JUNOS software uses this account to locally authenticate the user.

Each account requires two pieces of information: a login name (configured with the user statement) and a login class (configured with the class statement), which associates a set of privileges with the user, defining the scope of operations that can be performed on the router. As with Unix account names, the username must be unique on the network and cannot contain spaces, colons, or commas.

This recipe configures an account for the username sage, who has a privilege level operator, which allows her to perform most operational commands but not enter configuration mode. operator is one of the predefined privilege classes. Recipe 2.10 explains the other predefined classes and how to create custom privilege classes.

The set user sage full-name command configures the user's complete name. Setting this is optional, but you may find it convenient or easier to read the person's given name rather than her account name when checking the configuration to see who has access to a router. Enclose the full name in quotation marks if it contains spaces.

The third command, set user sage uid, assigns a user ID (UID) of 1991. The UID is basically the same as the Unix UID. It's included in the JUNOS configuration primarily because UIDs are integral to Unix systems and the JUNOS software runs on FreeBSD. As with Unix, the JUNOS software uses the UID when establishing and enforcing file permissions and file access. Configuring the UID is optional. If you do not configure it, the JUNOS software assigns one, generally using the lowest available UID number, starting at 2000. Here's an example of automatic assignment:

	[edit system 
login]
	aviva@router1# set user sage class operator
	aviva@router1# commit check
	configuration check succeeds
	aviva@router1# show
	user sage {
	 uid 2006;
	 class operator;
	}

You see that UID 2006 has been assigned to the user sage. You might want to explicitly configure the UID if users will be transferring files to Unix systems to ensure that users have the same UID on both JUNOS and Unix systems so that there are no file ownership issues.

The last command in this recipe establishes a plain-text password for the login account. You are prompted for the password, and nothing is displayed when you type and retype it.

To set up a user account, only the username and privilege class are required, but the password and other information are optional. If you omit the class, the CLI displays a warning:

	[edit system login]
	aviva@router1# set user sage full-name "sage david"
	aviva@router1# show
	user sage {
	 full-name "sage david";
	 ## Warning: missing mandatory statement(s): 'class'
	}

Also, you will not be able to commit a configuration if you forget to assign a class:

	[edit system 
login]
	aviva@router1# 
commit check
	[edit system login]
	 'user sage'
	 Missing mandatory statement: 'class'
	error: configuration check-out failed: daemon file propagation failed

If you configure a password with a user's login account the software authenticates the user against this password during the login process. This is the default authentication method. You should always configure passwords in the configuration file for at least a few users so there is always someone who can log in to the router.

If you configure a password with the user's login account but want the router to have a RADIUS or TACACS+ database authenticate the user before checking against the password configured on the router, you must change the authentication order so that the RADIUS or TACACS+ server is checked before the local user account (see Recipe 2.4). You must also configure RADIUS or TACACS+ user authentication (see Recipes 2.12 and 2.13). In this situation, users will be able to log in to the router if the remote authentication server fails.

If you do not configure a password with the user's login account, authentication is done only remotely, using a centralized RADIUS or TACACS+ authentication database, instead of locally based on the router configuration file. This type of account is analogous to a Unix account that has a * in the password field, which does not allow logins based on the password file but can allow logins based on other valid means of authentication, such as RADIUS. For this to work, you must change the authentication order so that RADIUS or TACACS+ is checked first (see Recipe 2.4), and you must configure the RADIUS or TACACS+ user authentication (see Recipes 2.12 and 2.13). Users with this type of account will not be able to log in to the router if the authentication server is down or if network problems occur when accessing the server.

You can also create a generic login account (see Recipe 2.8) or a group login account (see Recipe 2.9) instead of configuring individual accounts for each user. These types of accounts authenticate against the RADIUS or TACACS+ database. Here, too, you must change the authentication order so that RADIUS or TACACS+ is checked first (see Recipe 2.4), and you must configure the RADIUS or TACACS+ user authentication (see Recipes 2.12 and 2.13). Users with this type of account will not be able to log in to the router if the authentication server is not available.

This recipe configures a plain-text password for the user's authentication. The password must be at least six characters long and must contain at least one case or one letter-to-number change.(Recipe 2.6 explains how to modify the default password format.) Here, you type the plain-text-password keyword slightly differently than for some other JUNOS configuration statements. After you type plain-text-password, press Enter. The software then prompts you to type and then retype the password. Type the password in plain text, and the JUNOS management process, MGD, immediately encrypts it using SHA1 encryption by default. (To change the default encryption, see Recipe 2.7.) You then see only the encrypted version of the password. Notice that the keyword plain-text-password has changed to reflect the fact that the password is now encrypted:

	encrypted-password "$1$bO1I/WUw$bfaYF0LHxHxVCm7XyS7eG."; ## SECRET-DATA

To insert a previously encrypted DES, MD5, SHA1, SSH Version 1 ( RSA), or SSH Version 2 ( DSA) password, cut and paste (or type) the encrypted password into the configuration statement, enclosing it in quotation marks. Here is an example of an encrypted MD5 password:

	aviva@router1# set user sage authentication encrypted-password
	"$1$EpZ4gDEb$52KHLKA2QuqfJ83tFUvWd1"

You can define both encrypted and SSH passwords for a single user:

	aviva@router1# show
	user sage {
	 authentication {
	 encrypted-password "$1$kfpFHEom$wrWWtk69gvdbWInzsoI0b."; ## SECRET-DATA
	 ssh-rsa "1024 35 1463306454911004878538350206193424119843602248584695395
	55532106068887517531015448370922784460860638276095178917479848571459866004412524
	44671184497730460934239780966471256093384818219663350688876263790111832271705295
	56264636153739986671412936949237931460389138872790447839157168037660941582648407
	66391853943503 [e-mail]"; ## SECRET-DATA
	 }
	}

For basic router security considerations, you should limit access to the router to only those people who really need access, and you should carefully consider which privileges each person is given, so that a person can perform his job function and responsibilities, and nothing more.

See Also

Recipes 2.4, 2.6, 2.7, 2.8, 2.9, 2.10, 2.12, and 2.13