[ Contents] [ Prev] [ Next] [ Index] [ Report an Error]

Establishing a JUNOScript Session

The JUNOScript server communicates with client applications within the context of a JUNOScript session. The server and client explicitly establish a connection and session before exchanging data, and close the session and connection when they are finished. The streams of JUNOScript and JUNOS XML tag elements emitted by the JUNOScript server and a client application must each constitute a well-formed XML document by obeying the structural rules defined in the document type definition (DTD) for the kind of information they are exchanging. The client application must emit tag elements in the required order and only in the allowed contexts.

Client applications access the JUNOScript server using one of the protocols listed in Supported Access Protocols. To authenticate with the JUNOScript server, they use either a JUNOScript-specific mechanism or the protocol’s standard authentication mechanism, depending on the protocol. After authentication, the JUNOScript server uses the JUNOS login usernames and classes already configured on the routing platform to determine whether a client application is authorized to make each request.

For information about establishing a connection and JUNOScript session, see the following sections:

For an example of a complete JUNOScript session, see Example of a JUNOScript Session.

Supported Access Protocols

To connect to the JUNOScript server, client applications can use the access protocols and associated authentication mechanisms listed in Table 5.

Table 5: Supported Access Protocols and Authentication Mechanisms

Access Protocol

Authentication Mechanism

clear-text, a JUNOScript-specific protocol for sending unencrypted text over a Transmission Control Protocol (TCP) connection

JUNOScript-specific

SSH

Standard SSH

Outbound SSH

Outbound SSH

Secure Sockets Layer (SSL)

JUNOScript-specific

Telnet

Standard Telnet

The SSH and SSL protocols are preferred because they encrypt security information (such as passwords) before transmitting it across the network. Outbound SSH allows you to create an encrypted connection to the router in situations where you cannot connect to the router using standard SSH. The clear-text and Telnet protocols do not encrypt information.

For information about the prerequisites for each protocol, see Prerequisites for Establishing a Connection. For authentication instructions, see Authenticating with the JUNOScript Server.

Prerequisites for Establishing a Connection

To enable a client application to establish a connection to the JUNOScript server, you must satisfy the requirements discussed in the following sections:

Prerequisites for All Access Protocols

A client application must be able to log in to each routing platform on which it establishes a connection with the JUNOScript server. The following instructions explain how to create a JUNOS login account for the application; for detailed information, see the chapter about configuring user access in the JUNOS System Basics Configuration Guide. Alternatively, you can skip this section and enable authentication through RADIUS or TACACS+; for instructions, see the chapter about system authentication in the JUNOS System Basics Configuration Guide.

To determine whether a JUNOS login account exists, enter CLI configuration mode on the routing platform and issue the following commands:

[edit]
user@host# edit system login
[edit system login]
user@host# show user account-name

If the appropriate account does not exist, perform the following steps:

  1. Include the user statement at the [edit system login] hierarchy level. Also include the class statement to specify a JUNOS login class that has the permissions required for all actions to be performed by the application. Optionally, include the full-name and uid statements, which are described in the chapter about configuring user access in the JUNOS System Basics Configuration Guide.
    [edit system login]
    user@host# set user account-name class class-name
  2. Create a text-based password for the account by including either the plain-text-password or encrypted-password statement at the [edit system login user account-name authentication] hierarchy level.
    [edit system login]
    user@host# edit user account-name authentication

    Note: A text-based password is not strictly necessary if the account is used to access the JUNOScript server through SSH with public/private key pairs for authentication, but we recommend that you create one anyway. The key pair alone is sufficient if the account is used only for SSH access, but a password is required if the account is also used for any other type of access (for login on the console, for example). The password is also used—the SSH server prompts for it—if key-based authentication is configured but fails. For information about creating a public/private key pair, see Prerequisites for SSH Connections.

    To enter a password as text, issue the following command. You are prompted for the password, which is encrypted before being stored.

    [edit system login user account-name authentication]
    user@host# set plain-text-password
    New password: password
    Retype new password: password

    To store a password that you have previously created and hashed using Message Digest 5 (MD5) or Secure Hash Algorithm 1 (SHA-1), issue the following command:

    [edit system login user account-name authentication]
    user@host# set encrypted-password "password"
  3. Issue the commit command.

    [edit system login user account-name authentication]
    user@host# top
    [edit]
    user@host# commit
  4. Repeat the preceding steps on each routing platform where the client application establishes JUNOScript sessions.
  5. Enable the client application to access the password and provide it when the JUNOScript server prompts for it. There are several possible methods, including the following:

Prerequisites for Clear-Text Connections

A client application that uses the JUNOScript-specific clear-text protocol sends unencrypted text directly over a TCP connection without using any additional protocol (such as SSH, SSL, or Telnet).

Routers running the JUNOS-FIPS software do not accept JUNOScript clear-text connections. We recommend that you do not use the clear-text protocol in a Common Criteria environment. For more information, see the Secure Configuration Guide for Common Criteria and JUNOS-FIPS.

To enable client applications to use the clear-text protocol to connect to the JUNOScript server, perform the following steps:

  1. Verify that the application can access the TCP software. On most operating systems, TCP is accessible in the standard distribution.
  2. Satisfy the prerequisites discussed in Prerequisites for All Access Protocols.
  3. Configure the JUNOScript server to accept clear-text connections from JUNOScript client applications on port 3221 by including the xnm-clear-text statement at the [edit system services] hierarchy level:
    [edit]
    user@host# set system services xnm-clear-text

    By default, the JUNOScript server supports up to 75 simultaneous clear-text sessions and 150 connection attempts per minute. Optionally, you can include either or both the connection-limit statement to limit the number of concurrent sessions and the rate-limit statement to limit connection attempts. Both statements accept a value from 1 through 250.

    [edit]
    user@host# set system services xnm-clear-text connection-limit limit
    user@host# set system services xnm-clear-text rate-limit limit

    For more information about the xnm-clear-text statement, see the JUNOS System Basics Configuration Guide.

  4. Commit the configuration:
    [edit]
    user@host# commit
  5. Repeat Step on each computer where the application runs, and Step through Step on each routing platform to which the application connects.

Prerequisites for SSH Connections

To enable a client application to use the SSH protocol to connect to the JUNOScript server, perform the following steps:

  1. Enable the application to access the SSH software.

    If the application uses the JUNOScript Perl module provided by Juniper Networks, no action is necessary. As part of the installation procedure for the Perl module, you install a prerequisites package that includes the necessary SSH software. For instructions, see Downloading the JUNOScript Perl Client and Prerequisites Package.

    If the application does not use the JUNOScript Perl module, obtain the SSH software and install it on the computer where the application runs. For information about obtaining and installing SSH software, see http://www.ssh.com/ and http://www.openssh.com/ .

  2. Satisfy the prerequisites discussed in Prerequisites for All Access Protocols.
  3. (Optional) If you want to use key-based SSH authentication for the application, create a public/private key pair and associate it with the JUNOS Software login account you created in Prerequisites for All Access Protocols. Perform the following steps:
    1. Working on the computer where the client application runs, issue the ssh-keygen command in a standard command shell (not the JUNOS CLI). By providing the appropriate arguments, you encode the public key with either RSA (supported by SSH versions 1 and 2) or the Digital Signature Algorithm (DSA), supported by SSH version 2. For more information, see the man page provided by your SSH vendor for the ssh-keygen command. The JUNOS Software uses SSH version 2 by default but also supports version 1.
      % ssh-keygen options
    2. Enable the application to access the public and private keys. One method is to run the ssh-agent program on the computer where the application runs.
    3. Working in configuration mode on the routing platform that needs to accept SSH connections from JUNOScript client applications, associate the public key with the JUNOS login account by including the load-key-file statement at the [edit system login user account-name authentication] hierarchy level. First, move to that hierarchy level:
      [edit]
      user@host# edit system login user account-name authentication

      Issue the following command to copy the contents of the specified file onto the routing platform:

      [edit system login user account-name authentication]
      user@host# set load-key-file URL

      URL is the path to the file that contains one or more public keys. The ssh-keygen command by default stores each public key in a file in the .ssh subdirectory of the user home directory; the filename depends on the encoding (DSA or RSA) and SSH version. For information about specifying URLs, see the JUNOS CLI User Guide.

      Alternatively, you can include one or both of the ssh-dsa and ssh-rsa statements at the [edit system login user account-name authentication] hierarchy level. We recommend using the load-key-file statement, however, because it eliminates the need to type or cut and paste the public key on the command line. For more information about the ssh-dsa and ssh-rsa statements, see the JUNOS System Basics Configuration Guide.

  4. Configure the routing platform to accept SSH connections by including the ssh statement at the [edit system services] hierarchy level. This statement enables SSH access for all users and applications, not just JUNOScript client applications.
    [edit system login user account-name authentication]
    user@host# top
    [edit]
    user@host# set system services ssh
  5. Commit the configuration:
    [edit]
    user@host# commit
  6. Repeat Step on each computer where the application runs, and Step through Step on each routing platform to which the application connects.

Prerequisites for Outbound SSH Connections

The outbound SSH feature allows the initiation of an SSH session between routers running JUNOS Software and Network and System Management servers where client-initiated TCP/IP connections are blocked (for example, when the router is behind a firewall). To configure outbound SSH, you add an outbound-ssh configuration statement to the router. Once configured and committed, the router will begin to initiate outbound SSH sessions with the configured management clients. Once the outbound SSH session is initialized and the connection is established, the Network and System Management server initiates the SSH sequence as the client and the router running JUNOS Software, acting as the server, authenticates the client.

Setting up outbound SSH involves:

To configure the router for outbound SSH:

  1. Satisfy the prerequisites discussed in Prerequisites for All Access Protocols.
  2. In the [edit system services ssh] hierarchy level, set the SSH protocol to v2:
    [edit system services ssh]
    set protocol-version v2
  3. Generate/obtain a public/private key pair for the router running JUNOS Software. This key pair will be used to encrypt the data transferred across the SSH connection. For more information on generating key pairs, see the System Basics Configuration Guide.
  4. If the public key will be installed on the application management system manually, transfer the public key to the NSM server.
  5. Add the following outbound-ssh statement at the [edit system services] hierarchy level:
    [edit system services]
    outbound-ssh client {
    application-id {
    device-id device-id;
    secret secret;
    keep-alive {
    retry number;
    timeout number;
    }
    reconnect-strategy (sticky | in-order) ;
    services netconf;
    address {
    port destination-port;
    retry number;
    timeout number;
    }
    }
    }

    The attributes are as follows:

  6. Commit the configuration:
    [edit]
    user@host# commit

To set up the Network and Systems Management Server:

  1. Satisfy the prerequisites discussed in Prerequisites for All Access Protocols.
  2. Enable the application to access the SSH software.
  3. (Optional) Manually install the router's public key for use with the SSH connection.
  4. Configure the client system to receive an process initialization broadcast requests. The intialization requests use the following syntax:

Prerequisites for SSL Connections

To enable a client application to use the SSL protocol to connect to the JUNOScript server, perform the following steps:

  1. Enable the application to access the SSL software.

    If the application uses the JUNOScript Perl module provided by Juniper Networks, no action is necessary. As part of the installation procedure for the Perl module, you install a prerequisites package that includes the necessary SSL software. For instructions, see Downloading the JUNOScript Perl Client and Prerequisites Package.

    If the application does not use the JUNOScript Perl module, obtain the SSL software and install it on the computer where the application runs. For information about obtaining and installing the SSL software, see http://www.openssl.org/ .

  2. Satisfy the prerequisites discussed in Prerequisites for All Access Protocols.
  3. Use one of the following two methods to obtain an authentication certificate in privacy-enhanced mail (PEM) format:
  4. Import the certificate onto the routing platform by including the local statement at the [edit security certificates] hierarchy level and the load-key-file statement at the [edit security certificates local certificate-name] hierarchy level.
    [edit]
    user@host# edit security certificates local certificate-name
     
    [edit security certificates local certificate-name]
    user@host# set load-key-file URL-or-path

    certificate-name is a name you choose to identify the certificate uniquely (for example, junoscript-ssl-client-hostname, where hostname is the computer where the client application runs).

    URL-or-path specifies the file that contains the paired certificate and private key (if you issued the openssl command in Step , the certificate-name.pem file). Specify either the URL to its location on the client computer or a pathname on the local disk (if you have already used another method to copy the certificate file to the router’s local disk). For more information about specifying URLs and pathnames, see the JUNOS CLI User Guide.

    Note: The CLI expects the private key in the URL-or-path file to be unencrypted. If the key is encrypted, the CLI prompts you for the passphrase associated with it, decrypts it, and stores the unencrypted version.

    The set-load-key-file URL-or-path command copies the contents of the certificate file into the configuration. When you view the configuration, the CLI displays the string of characters that constitute the private key and certificate, marking them as SECRET-DATA. The load-key-file keyword is not recorded in the configuration.

  5. Configure the JUNOScript server to accept SSL connections from JUNOScript client applications on port 3220 by including the xnm-ssl statement at the [edit system services] hierarchy level.
    [edit security certificates local certificate-name]
    user@host# top
    [edit]
    user@host# set system services xnm-ssl local-certificate certificate-name

    certificate-name is the unique name you assigned to the certificate in Step .

    By default, the JUNOScript server supports up to 75 simultaneous SSL sessions and 150 connection attempts per minute. Optionally, you can include either or both the connection-limit statement to limit the number of concurrent sessions and the rate-limit statement to limit connection attempts. Both statements accept a value from 1 through 250.

    [edit]
    user@host# set system services xnm-ssl connection-limit limit
    user@host# set system services xnm-ssl rate-limit limit

    For more information about the xnm-ssl statement, see the JUNOS System Basics Configuration Guide.

  6. Commit the configuration:
    [edit]
    user@host# commit
  7. Repeat Step on each computer where the application runs, and Step through Step on each routing platform to which the application connects.

Prerequisites for Telnet Connections

To enable a client application to use the Telnet protocol to access the JUNOScript server, perform the steps described in this section.

Routers running the JUNOS-FIPS software do not accept Telnet connections. We recommend that you do not use the Telnet protocol in a Common Criteria environment. For more information, see the Secure Configuration Guide for Common Criteria and JUNOS-FIPS.

  1. Verify that the application can access the Telnet software. On most operating systems, Telnet is accessible in the standard distribution.
  2. Satisfy the prerequisites discussed in Prerequisites for All Access Protocols.
  3. Configure the routing platform to accept Telnet connections by including the telnet statement at the [edit system services] hierarchy level. This statement enables Telnet access for all users and applications, not just JUNOScript client applications.
    [edit]
    user@host# set system services telnet
  4. Repeat Step on each computer where the application runs, and Step and Step on each routing platform to which the application connects.

Connecting to the JUNOScript Server

For a client application to connect to the JUNOScript server and open a session, you must first satisfy the prerequisites described in Prerequisites for Establishing a Connection.

When the prerequisites are satisfied, an application written in Perl can most efficiently establish a connection and open a session by using the JUNOScript Perl module provided by Juniper Networks. For more information, see Writing Perl Client Applications.

A client application that does not use the JUNOScript Perl module connects to the JUNOScript server by opening a socket or other communications channel to the JUNOScript server machine (routing platform), invoking one of the remote-connection routines appropriate for the programming language and access protocol that the application uses.

What the client application does next depends on which access protocol it is using:

Connecting to the JUNOScript Server from the CLI

The JUNOScript XML API and JUNOS XML API are primarily intended for use by client applications; however, for testing you can establish an interactive JUNOScript session and type commands in a shell window. To connect to the JUNOScript server from CLI operational mode, issue the junoscript interactive command (the interactive option causes the JUNOScript server to echo what you type):

user@host> junoscript interactive

To begin a JUNOScript session over the connection, emit the initialization PI and tag that are described in Emitting the Initialization PI and Tag. You can then type sequences of tag elements that represent operational and configuration operations, which are described in Requesting Information, Changing Configuration Information, and Committing a Configuration. To eliminate typing errors, save complete tag element sequences in a file and use a cut-and-paste utility to copy the sequences to the shell window.

Note: When you close the connection to the JUNOScript server (for example, by emitting the <request-end-session/> and </junoscript> tags), the routing platform completely closes your connection instead of returning you to the CLI operational mode prompt. For more information about ending a JUNOScript session, see Ending a JUNOScript Session and Closing the Connection.

Starting the JUNOScript Session

Each JUNOScript session begins with a handshake in which the JUNOScript server and the client application specify the versions of XML and the JUNOScript API they are using. Each party parses the version information emitted by the other, using it to determine whether they can communicate successfully. The following sections describe how to start a JUNOScript session:

Emitting the Initialization PI and Tag

When the JUNOScript session begins, the client application emits an <?xml?> PI and an opening <junoscript> tag, as described in the following sections:

Emitting the <?xml?> PI

The client application begins by emitting an <?xml?> PI.

Note: In the following example (and in all examples in this document of tag elements emitted by a client application), bold font is used to highlight the part of the tag sequence that is discussed in the text.

      <?xml version="version" encoding="encoding"?>
    

The attributes are as follows. For a list of the attribute values that are acceptable in the current version of the JUNOScript API, see Supported Software Versions.

In the following example of a client application’s <?xml?> PI, the version="1.0" attribute indicates that the application is emitting tag elements that comply with the XML 1.0 specification. The encoding="us-ascii" attribute indicates that the client application is using the 7-bit ASCII character set standardized by the American National Standards Institute (ANSI). For more information about ANSI standards, see http://www.ansi.org/ .

<?xml version="1.0" encoding="us-ascii"?>

Note: If the application fails to emit the <?xml?> PI before emitting the opening <junoscript> tag, the JUNOScript server emits an error message and immediately closes the session and connection. For more information, see Emitting the Opening <junoscript> Tag.

Emitting the Opening <junoscript> Tag

The client application then emits its opening <junoscript> tag, which has the following syntax (and appears here on two lines only for legibility):

<junoscript version="version" hostname="hostname" junos:key="key"
     release="release-code">

The attributes are as follows. For a list of the attribute values that are acceptable in the current version of the JUNOScript API, see Supported Software Versions.

In the following example of a client application’s opening <junoscript> tag, the version="1.0" attribute indicates that it is using JUNOScript version 1.0. The hostname="client1" attribute indicates that the client application is running on the machine called client1. The release="10.0R1" attribute indicates that the routing platform is running the initial version of JUNOS Release 10.0.

<junoscript version="1.0" hostname="client1" release="10.0R1">

Note: If the application fails to emit the <?xml?> PI before emitting the opening <junoscript> tag, the JUNOScript server emits an error message similar to the following and immediately closes the session and connection:

<rpc-reply>
    <xnm:error xmlns="http://xml.juniper.net/xnm/1.1/xnm" \             xmlns:xnm="http://xml.juniper.net/xnm/1.1/xnm">         <message>
            communication error while exchanging credentials         </message>
    </xnm:error> </rpc-reply>
<!- - session end at YYYY-MM-DD hh:mm:ss TZ - ->
</junoscript>

For more information about the <xnm:error> tag, see Handling an Error or Warning.

Parsing the Initialization PI and Tag from the JUNOScript Server

When the JUNOScript session begins, the JUNOScript server emits an <?xml?> PI and an opening <junoscript> tag, as described in the following sections:

Parsing the JUNOScriptServer’s <?xml?> PI

The syntax for the <?xml?> PI is as follows:

<?xml version="version" encoding="encoding"?>

The attributes are as follows. For a list of the attribute values that are acceptable in the current version of the JUNOScript API, see Supported Software Versions.

In the following example of a JUNOScript server’s <?xml?> PI, the version="1.0" attribute indicates that the server is emitting tag elements that comply with the XML 1.0 specification. The encoding="us-ascii" attribute indicates that the server is using the 7-bit ASCII character set standardized by ANSI. For more information about ANSI standards, see http://www.ansi.org/ .

<?xml version="1.0" encoding="us-ascii"?>

Parsing the JUNOScriptServer’s Opening <junoscript> Tag

The server then emits its opening <junoscript> tag, which has the following form (the tag appears on multiple lines only for legibility):

<junoscript xmlns="namespace-URL" xmlns:junos="namespace-URL" \
    schemaLocation="namespace-URL" os="JUNOS" \
    release="release-code" hostname="hostname" version="version">

The attributes are as follows:

In the following example of a JUNOScript server’s opening <junoscript> tag, the version attribute indicates that the server is using JUNOScript version 1.0, and the hostname attribute indicates that the routing platform’s name is big-router. The os and release attributes indicate that the routing platform is running the initial version of JUNOS Release 10.0. The xmlns and xmlns:xnm attributes indicate that the default namespace for JUNOS XML tag elements and the namespace for tag elements that have the xnm: prefix is http://xml.juniper.net/xnm/1.1/xnm . The xmlns:junos attribute indicates that the namespace for tag elements that have the junos: prefix is http://xml.juniper.net/junos/10.0R1/junos . The tag appears on multiple lines only for legibility.

<junoscript xmlns="http://xml.juniper.net/xnm/1.1/xnm"\
    xmlns:junos="http://xml.juniper.net/junos/10.0R1/junos" \
    schemaLocation="http://xml.juniper.net/junos/10.0R1/junos" os="JUNOS" \
    release="10.0R1" hostname="big-router" version="1.0">
    

Verifying Software Compatibility

Exchanging <?xml?> and <junoscript> tag elements enables a client application and the JUNOScript server to determine if they are running different versions of the software used during a JUNOScript session. Different versions are sometimes incompatible, and by JUNOScript convention the party running the later version of software determines how to handle any incompatibility. For fully automated performance, include code in the client application that determines if its version of software is later than that of the JUNOScript server. Decide which of the following options is appropriate when the application’s version is more recent, and implement the corresponding response:

Supported Software Versions

Table 6 lists the versions of software supported by version 1.0 of the JUNOScript API and specifies the PI or opening tag and attribute used to convey version information during JUNOScript session initialization.

Table 6: Supported Software Versions

Software and Versions

PI or Tag

Attribute

XML 1.0

<?xml?>

version="1.0"

ANSI-standardized 7-bit ASCII character set

<?xml?>

encoding="us-ascii"

JUNOScript 1.0

<junoscript>

version="1.0"

JUNOS Release 8.0
JUNOS Release 8.2
JUNOS Release 8.3

<junoscript>

release="8.0R x ?"
release="8.2R
x ?"
release="8.3R
x ?"

Authenticating with the JUNOScript Server

A client application that uses the clear-text or SSL protocol must now authenticate with the JUNOScript server. (Applications that use the SSH or Telnet protocol use the protocol’s built-in authentication mechanism before emitting initialization tag elements, as described in Connecting to the JUNOScript Server.)

See the following sections:

Submitting an Authentication Request

The client application begins the authentication process by emitting the <request-login> tag element within an <rpc> tag element. In the <request-login> tag element, it encloses the <username> tag element to specify the JUNOS account (username) under which to establish the connection. The account must already be configured on the JUNOScript server machine, as described in Prerequisites for All Access Protocols. You can choose whether or not the application provides the account password as part of the initial tag sequence.

Providing the Password with the Username

To provide the password along with the username, the application emits the following tag sequence:

<rpc>
    <request-login>
        <username>username</username>
        <challenge-response>password</challenge-response>
    </request-login>
</rpc>

This tag sequence is appropriate if the application automates access to routing platform information and does not interact with users, or obtains the password from a user before beginning the authentication process.

Providing Only the Username

To omit the password and specify only the username, the application emits the following tag sequence:

<rpc>
    <request-login>
        <username>username</username>
    </request-login>
</rpc>

This tag sequence is appropriate if the application does not obtain the password until the authentication process has already begun. In this case, the JUNOScript server returns the <challenge> tag element within an <rpc-reply> tag element to request the password associated with the username. The tag element encloses the Password: string, which the client application can forward to the screen as a prompt for a user. The echo="no" attribute in the opening <challenge> tag specifies that the password string typed by the user does not echo on the screen. The tag sequence is as follows:

<rpc-reply xmlns:junos="URL">
    <challenge echo="no">Password:</challenge>
</rpc-reply>

The client application obtains the password and emits the following tag sequence to forward it to the JUNOScript server:

<rpc>
    <request-login>
        <username>username</username>
        <challenge-response>password</challenge-response>
    </request-login>
</rpc>

Interpreting the Authentication Response

After it receives the username and password, the JUNOScript server emits the <authentication-response> tag element to indicate whether the authentication attempt is successful.

Server Response When Authentication Succeeds

If the password is correct, the authentication attempt succeeds and the JUNOScript server emits the following tag sequence:

<rpc-reply xmlns:junos="URL">
    <authentication-response>
        <status>success</status>
        <message>username</message>
        <login-name>remote-username</login-name>
    </authentication-response>
</rpc-reply>

The <message> tag element contains the JUNOS username under which the connection is established.

The <login-name> tag element contains the username that the client application provided to an authentication utility such as RADIUS or TACACS+. This tag element appears only if the username differs from the username contained in the <message> tag element.

The JUNOScript session begins, as described in Starting the JUNOScript Session.

Server Response When Authentication Fails

If the password is not correct or the <request-login> tag element is otherwise malformed, the authentication attempt fails and the JUNOScript server emits the following tag sequence:

<rpc-reply xmlns:junos="URL">
    <authentication-response>
        <status>fail</status>
        <message>error-message</message>
    </authentication-response>
</rpc-reply>

The error-message string in the <message> tag element explains why the authentication attempt failed. The JUNOScript server emits the <challenge> tag element up to two more times before rejecting the authentication attempt and closing the connection.


[ Contents] [ Prev] [ Next] [ Index] [ Report an Error]