Authenticate Users Executing Ansible Modules on Junos Devices

You can explicitly define the connection and authentication parameters for modules that manage Junos devices. If you do not define a parameter, the module uses a default value in some cases. Table 1 outlines the default values and variable precedence for common connection parameters for the juniper.device module set. For information about the arguments accepted for the individual modules, see the API reference documentation for that module.

When executing the Juniper Networks modules, the host argument is always required for a connection. However, you do not have to explicitly specify the host because it defaults to {{ inventory_hostname }}.

You can execute the modules using any user account that has access to the managed Junos device. Junos OS user account access privileges are enforced, and the class configured for the Junos OS user determines the permissions. If you do not specify a user, the user is set according to the algorithm described for user in Table 1. See the Ansible documentation for the precedence used to define remote_user, which can be set in a number of ways, including:

• -u or --user command line option

• ANSIBLE_REMOTE_USER environment variable

• remote_user configuration setting

You can define connection and authentication parameters for the juniper.device modules in the play’s vars: section. This option is in addition to defining the parameters through other means, for example, in the SSH configuration file, in the Ansible inventory file, as command-line arguments, or as module arguments. The vars: section enables you to define common connection parameters in a single location that all modules in the play can use to connect to a host. Additionally, certain Ansible connections require using the vars: section when you define the parameters within the play, as described here.

The juniper.device modules support the following Ansible connections types:

• Local connections, which are defined by using connection: local

• Persistent connections, which are defined by using connection: juniper.device.pyez

For both local and persistent connections, Ansible executes modules locally on the control node. When you use connection: local, Ansible establishes a separate connection to the host for each task in the play that requires a connection. By contrast, when you use connection: juniper.device.pyez, Ansible establishes a single, persistent connection to a host, which persists over the execution of all tasks in the play.

You use the same connection and authentication parameters for persistent connections as you do for local connections, and the default parameter values apply to both types of connections. For local connections, you can define the connection and authentication parameters either in the vars: section or as module arguments. If you define the parameters in both places, the module arguments take precedence. However, when you define parameters within a play for persistent connections, you must define the parameters in the vars: section. With persistent connections there is only a single connection for all tasks, and thus you must define the parameters globally so they apply to all tasks in that play.

The following playbook executes two juniper.device modules on each host in the inventory group. The play defines the Ansible connection as juniper.device.pyez, which establishes a connection to each host that persists over the execution of all tasks in the play. The play’s vars: section defines the authentication parameters for the persistent connection. The user and passwd values reference variables defined in the vault-vars.yaml vault file.

To authenticate a user executing Ansible modules, you can prompt for the user’s credentials when you execute the playbook. For example, you can define an interactive prompt in the playbook, or you can execute the playbook with the -k or --ask-pass command-line option to prompt for the password. When SSH keys are in use, the supplied password is used as the private SSH key passphrase. When password-based authentication is used, the supplied password is used as the device password.

To define an interactive prompt in the playbook to obtain the user’s password or SSH key passphrase:

You can use Ansible vault to securely store passwords and other sensitive connection and authentication values in a vault-encrypted data file. Your playbook can then reference those variables in the location appropriate for your set of modules and Ansible connection type, for example, in the play’s vars: section or as module arguments.

This example uses Ansible vault to create and encrypt a new vault file. You can also encrypt individual variables or use multiple encrypted files with different passwords. See the official Ansible documentation for detailed information about using Ansible vault for encrypting content and files.

To create and use an Ansible vault file containing required variables, including passwords:

The Juniper Networks Ansible modules can connect to Junos devices through a console server. For SSH connections through a console server, you need to provide the authentication credentials for both the console server and the Junos device. You can use either a device password or a password-protected SSH key file for the console server authentication.

To connect to a Junos device through a console server, you must provide the following parameters in your playbook, if there is no default value or the default value is not appropriate:

• host—Console server hostname or IP address

• user and passwd—Junos OS login credentials

• cs_user—Console server username

• cs_passwd—Device password or SSH key file passphrase required to authenticate with the console server

• port—Port, if different from the default

In the following example, the credentials for the Junos OS user and the console server user are defined in an Ansible vault file. The vault variables are then referenced in the playbook. In this case, the cs_passwd argument is the passphrase for the SSH key specified in the ssh_private_key_file argument.