Junos User Accounts: Login Classes, SSH Keys and Root Auth

2026年9月5日 LOG admin

Every engineer who logs into a Junos device needs a user account tied to a login class, which defines the permissions that account carries. Junos stores these accounts in the configuration under [edit system login], so they are versioned, rolled back and pushed to other devices just like any other config — and SSH public keys are configured the same way. This guide creates user accounts from the CLI, explains the predefined login classes, and sets up key-based authentication.

The fact that accounts live in the configuration is the single most important design fact about Junos user management. There is no separate local user database to back up, no write memory step, and no way to have a working account that is invisible to show configuration. That makes auditing trivial and it makes rollout trivial: extract the block, put it in a configuration group, and every device that applies the group receives the same accounts. It also means an account change is a configuration change, subject to commit, rollback and confirmation exactly like a routing change.

Understanding Login Classes

Junos ships four predefined login classes. Permission bits (clear, network, reset, trace, view, maintenance, super-user, and so on) define exactly which commands an account may run:

super-user — all permissions.
operator — clear, network, reset, trace and view; can troubleshoot but not reconfigure.
read-only — view only.
unauthorized — no permissions (useful for locked-down audit accounts).

The permission bits are the real access-control mechanism, and they are granular enough to build a class that exactly matches a job function. The bits you will use most often are configure (enter configuration mode), view (read the configuration and operational output), network (run basic networking commands such as ping and traceroute), clear (reset counters, clear sessions and OSPF adjacencies), trace (view trace files), firewall (view filters and policies), interface, routing, snmp, system (manage the chassis), shell (drop into the FreeBSD shell), and super-user which implies the lot. A custom class that lets a NOC engineer clear counters and run traces but never commit a change looks like this:


[edit system login]
user@host# set class noc-engineer permissions [ view network clear trace]
user@host# set class ipsec-ops permissions [ view network clear trace configure firewall]
user@host# set class auditors permissions [ view]
user@host# set class auditors allow-commands "show configuration"
user@host# set class auditors deny-commands "configure|edit|set|delete|commit"

Note the last two lines: allow-commands and deny-commands take regular expressions and let you tighten a class beyond what permission bits allow. Denials always win over allowances, so the pattern above produces a genuinely read-only class even if someone later adds a broader permission. If you build classes that are too permissive, the fix is a commit confirmed away — the same safety net described in the commit-confirmed and rollback guide linked below.

Creating a User Account

Add the user, optionally set a full name and UID (100–64000), assign the login class, then choose the authentication method:


[edit system login]
set user jsmith full-name "John Smith"
set user jsmith uid 2001
set user jsmith class operator
set user jsmith authentication plain-text-password
New password:
Retype new password:

With plain-text-password Junos prompts twice and stores the result encrypted (shown as ## SECRET-DATA in the configuration). Only use encrypted-password when you already hold an encrypted hash — pasting a plain-text password there locks the account out.

The ## SECRET-DATA marker is worth understanding rather than trusting blindly. It means the configuration contains a value that Junos will not display, and it survives show configuration, display set and even a configuration export. The consequence is that you cannot copy a password hash from one device to another by reading the config; if you want identical credentials across a fleet, generate the hash once on a device where you control the source and store it in whatever system-of-record you use for configuration templates. The UID is optional but useful when you integrate with a RADIUS server or with SNMPv3 user models, where a stable numeric identity is expected. Keep UIDs consistently mapped: reusing a UID for two local accounts causes warnings and, on some platforms, unpredictable authorisation.

SSH Key Authentication

Paste the public key directly, or load it from a file with load-key-file, which copies the key into the configuration immediately:


[edit system login]
set user jsmith authentication ssh-rsa "ssh-rsa AAAAB3NzaC1yc2E... user@laptop"


[edit system login]
set user jsmith authentication load-key-file /tmp/jsmith.pub

Junos accepts several key types, and the choice matters because it determines the algorithms your clients may negotiate: ssh-rsa for classic RSA, ssh-ecdsa for ECDSA, and ssh-ed25519 for Ed25519 keys. Modern clients prefer Ed25519, so if you are standardising on key-only authentication, configure at least ssh-ed25519 alongside ssh-rsa so that older tooling still connects. A common and reasonable policy is to allow RSA only for legacy jump hosts and Ed25519 everywhere else:


set user jsmith authentication ssh-ed25519 "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5... jsmith@laptop"
set user jsmith authentication ssh-rsa "ssh-rsa AAAAB3NzaC1yc2E... jsmith@jump"
set user jsmith authentication password "<hash>"

When both a key and a password are configured, either will authenticate the session; the key does not replace the password. If you want an account that can only use a key, configure the key alone and omit the password or plain-text-password statement. Two practical notes. First, load-key-file is the safest way to enter a long key because it removes the line-wrapping and quoting errors that plague copy-paste from email or chat. Second, the comment at the end of the key (the user@laptop part) is stored verbatim; putting the owner and origin in it makes later audits far easier, because show configuration system login becomes a readable inventory of who has access and from where.

Key-based access is also the natural companion to the management-plane hardening you would do on an SRX, and the same account model applies there, and user/AAA design is the first step of any device build.

Root Authentication

The root account always exists; set its authentication separately under root-authentication. For out-of-band console recovery scenarios, keep a plain-text-capable method configured:


[edit system root-authentication]
set encrypted-password "$6$..."
set ssh-rsa "ssh-rsa AAAAB3NzaC1yc2E... admin@bastion"

Root is special for two reasons. It cannot be deleted, so it is the one account guaranteed to exist after any rollback or rescue restore; and it is the account the platform uses for internal operations and for the console. That makes it the account you fall back to when every other path is broken. The trade-off is that root on a network device is a high-value target: prefer a long random passphrase kept in a password manager, restrict SSH to the management network, and put the password in the same sealed process you use for console access to the site. If you ever do lose it, the recovery path is well documented in our Junos root password recovery guide and requires physical console access — which is exactly why the console must never be the only credential you control.

Some platforms also support root-authentication with password (a plain-text password hashed at commit). Use encrypted-password when you have a hash, and the interactive plain-text-password variant when you want to be prompted; avoid storing recoverable plain text anywhere it can be read.

RADIUS, TACACS+ and the Authentication Order

Local accounts exist so the device is manageable when the AAA server is not. In production, centralise authentication and keep exactly one or two local break-glass accounts:


[edit system]
set authentication-order [ radius password]
set radius-server 192.0.2.50 secret "shared-secret"
set tacplus-server 192.0.2.51 secret "tacacs-secret"
set accounting destination radius server 192.0.2.50 secret "shared-secret"

The order matters in a specific way: Junos tries each method in sequence and stops at the first success, but a method that rejects the credentials also stops the sequence, while a method that is unreachable moves on to the next. That behaviour is what makes [ radius password ] safe — if the RADIUS server is down, the local password is tried, but a user whose RADIUS password is simply wrong cannot fall through and try a local account. TACACS+ is usually preferred for device administration because it authorises per-command rather than per-session, which maps naturally onto the login-class permission model; RADIUS is simpler and often already present for VPN and wireless. Whichever you choose, the same comparative notes apply as on other vendors' platforms, covered in our Arista EOS AAA: TACACS+ and RADIUS configuration article.

Applying and Verifying


[edit]
commit

Log out and back in as the new user to confirm the class grants the intended access. Inspect accounts and their classes at any time:


show configuration system login
show configuration system login user jsmith
show system users
show cli authorization

Do not skip the login test. A login class that looks correct on paper can still fail in practice: the account may fall through to a class that permits configure but not the specific commit, or a deny-commands regex may match more than you intended. Signing in as the new user and running one representative command from each category they need is the only reliable check, and it takes a minute. show system users then gives you a live view of who is logged in and from which address, which doubles as a simple access audit.

To roll the same accounts out to many devices, put them inside a configuration group and apply the group — covered in the Junos user-access documentation:


set groups AAA-USERS system login user jsmith class operator
set groups AAA-USERS system login user jsmith authentication ssh-rsa "ssh-rsa AAAAB... jsmith@laptop"
set apply-groups AAA-USERS
commit check
show configuration | display set | match AAA-USERS

commit check before commit is a good habit when you are spreading a group across a fleet, because it validates the whole candidate configuration without applying it. If the check fails, nothing on the network has changed. Keep the group definition in your configuration source of truth rather than editing it device by device, and the account inventory stays accurate without anyone maintaining it by hand.

Locking Down and Auditing Accounts

Give every human their own account; shared logins destroy accountability and make key rotation impossible.
Use full-name and a key comment so show configuration reads as an access review.
Assign the weakest class that does the job — read-only for helpdesk and monitoring integrations.
Remove accounts that no longer need access; a stale account survives every hardware refresh because it lives in the configuration.
Reserve the unauthorized class for accounts that must exist but must never be able to do anything.
Re-audit after any acquisition, handover or contractor offboarding, using the group definition as the checklist.