Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

NETCONF Call Home Sessions

SUMMARY NETCONF Call Home enables a NETCONF server to initiate a secure connection to a NETCONF client. The NETCONF client can then establish an SSH session and NETCONF session with the server.

NETCONF Call Home enables a NETCONF client to remotely manage Junos devices in cases where the client cannot initiate a connection to the network device. The Junos device that is acting as the NETCONF server initiates and maintains secure connections to a predefined set of NETCONF clients. The following sections discuss the NETCONF Call Home feature.

Understanding NETCONF Call Home

NETCONF Call Home Overview

For normal NETCONF sessions over SSH, the NETCONF client first initiates a TCP connection to the Junos device that is acting as the NETCONF server. The client then starts the SSH session followed by the NETCONF session. In a NETCONF call home scenario, the roles of the TCP server and client are reversed. The NETCONF server initiates the TCP connection to the NETCONF client. After the connection is established, the NETCONF client then starts the SSH session and NETCONF session as normal.

NETCONF Call Home enables you to remotely manage Junos devices that might not be otherwise accessible. This might happen, for example, if the device is behind a firewall, and the firewall or another security tool restricts management access to the device or implements Network Address Translation (NAT). In such cases, the NETCONF client might not be able to initiate the connection with the Junos device. However, you can configure the Junos device to initiate, establish, and maintain a connection with a predefined set of network management systems.

You can use NETCONF Call Home in the following scenarios:

  • Initial deployment

  • General device management

Figure 1 outlines the call home sequence. In a NETCONF call home scenario, the network management system (NMS) is the TCP server, and the Junos device is the TCP client. You configure the TCP server to listen for connection requests on a specified port. The NETCONF Call Home standard port is 4334, but you can configure any valid port number that does not conflict with another service. You configure the Junos device to connect to one or more predefined network management systems on the specified port. After the devices establish a TCP connection, the NMS assumes its role as SSH client and NETCONF client.

Figure 1: NETCONF Call Home Connection NETCONF Call Home Connection

The NETCONF client initiates an SSH session over the TCP connection. During SSH session establishment, the NETCONF client must authenticate the server by validating the server's presented host key or certificate. The NETCONF server must also authenticate the client. The client can choose any SSH authentication method supported by the server. The server first checks certificate-based authentication, then key-based authentication, and finally password-based authentication.

We recommend using SSH certificate-based authentication for users and hosts. Certificate-based authentication enables you to set up SSH access to a device with password-less login for users and gives the capability to trust hosts without the need to verify key fingerprints. Additionally, you can define the length of time that a given certificate is valid. For certificate-based authentication, the server and client each send their SSH certificate. You must configure the client with the CA public key that verifies the server's certificate. Similarly, you must configure the server with the CA public key that verifies the client's certificate.

For more information about NETCONF Call Home, see RFC 8071, NETCONF Call Home and RESTCONF Call Home.

Benefits of NETCONF Call Home

  • NETCONF Call Home can streamline the initial deployment of devices.

  • NETCONF Call Home using certificate-based authentication can simplify the management and scaling of authentication keys and offer stronger security compared to traditional password-based approaches.

How to Set Up NETCONF Call Home

To configure NETCONF Call Home, perform the steps described in the following sections:

Configure the Junos User Account

For all SSH authentication methods, the NETCONF client needs a local user account or user template account on each device where it establishes a NETCONF session.

To create a local user template account:

  1. Configure the user statement at the [edit system login] hierarchy level and specify a username. Include the class statement, and specify a login class that has the permissions required for all actions to be performed by the user.

  2. Commit the configuration

  3. Repeat the preceding steps on each Junos device where the client application establishes NETCONF sessions.

Configure SSH Authentication

During SSH session establishment, the NETCONF client authenticates the server by validating the server's presented host key or certificate. Similarly, the NETCONF server authenticates the client. The server first checks certificate-based authentication, then key-based authentication, and finally password-based authentication. You must configure the server and client for whichever authentication method you choose. The SSH authentication methods are described in the following sections:

Configure Password-Based Authentication

If the NETCONF client uses password-based authentication, configure the Junos user account with a password.

To create a text-based password:

  1. Include the plain-text-password or encrypted-password statement for the user account.

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

      To store a pre-encrypted password, for example, a password that you previously created and hashed using Message Digest 5 (MD5), issue the following command:

  2. Commit the configuration.

  3. Repeat the preceding steps on each Junos device where the client application establishes NETCONF sessions using password-based authentication.

Configure Key-Based Authentication

If the NETCONF client uses key-based authentication, first generate the user's SSH key pair on the configuration management server. Then configure the public key under the corresponding user account on the Junos device.

To configure key-based authentication for the NETCONF client:

  1. Generate the SSH key pair for the given user.

    On the network management system, issue the ssh-keygen command and provide the appropriate arguments.

    For example:

    By default, the ssh-keygen command stores the public and private keys in files in the .ssh subdirectory of the user home directory; the filename depends on the encoding and SSH version. See the ssh-keygen manual page for more information about the command options.

  2. On the Junos device, associate the public key with the Junos login account for that user.

    Junos OS copies the contents of the specified file onto the device running Junos OS. URL is the path to the file that contains one or more public keys. For information about specifying URLs, see the CLI User Guide.

    Note:

    Alternatively, you can configure the public key by including the ssh-rsa or equivalent statement at the [edit system login user username authentication] hierarchy level.

  3. Commit the configuration.

  4. Repeat the steps for configuring the public key on each Junos device where the client application establishes a NETCONF session.

During the initialization of the SSH connection, the client can authenticate the identity of the NETCONF server by using the server's public key. You can either install the server's public key on the network management system, or you can pass in the key during session initialization.

Configure Certificate-Based Authentication

NETCONF Call Home supports using SSH certificates for authentication. An SSH certificate comprises an SSH public key that has been signed by a certificate authority (CA). A CA private key (signing key) signs the host public key to generate the host certificate. Similarly a CA private key signs the user public key to generate the user certificate. The host certificate authenticates the host to users, and the user certificate authenticates the user to hosts.

You can use OpenSSH to create SSH certificates and the associated CA infrastructure. The OpenSSH certificate specifies a public key, identity information, and validity constraints. To use SSH certificates for authentication you must:

  • Create the certificate authorities and generate the CA signing keys.

  • Generate the user's SSH key pair.

  • Generate the user and host certificates by using the CA private key to sign the user public key and host public key.

  • Configure the CA public key as trusted on the Junos device and the network management system.

  • Configure the authorized principals on the Junos device.

By default, generated certificates are valid for all users. To limit the user certificate to a specific set of users (principals), you must specify the authorized principals when you generate the certificate. Junos devices require certificates that specify one or more authorized principals. You must also configure the list of authorized principals on the Junos device. If any authorized principal configured on the device matches an authorized principal in the certificate, the device authenticates the certificate. The connecting user is authorized even if they are not explicitly configured as an authorized principal in the certificate or on the device.

To configure certificate-based authentication, perform the following steps:

Generate the Certificate Authorities

  1. On any Linux/FreeBSD system, generate the certificate authority signing keys.

    For example, the following commands create separate CA signing keys for signing the user and host certificates.

  2. Configure the network management system to trust the host CA.

    Copy the contents of the host CA public key and add it to the global or user's SSH known hosts file to mark it as a trusted CA. In the following example, we copy the host CA public key contents and add @cert-authority * host-ca-public-key to the user's known_hosts file.

    Note:

    The NMS uses the host CA public key to verify the host certificate. To trust the certificate for only specific hosts or domains, replace the wildcard (*) with the appropriate host or domain names.

  3. Copy the user CA public key to the Junos device.

    For example:

  4. On the Junos device, configure the user CA public key as a trusted CA key.

    The following example adds the CA public key that is stored in the user_ca.pub file as a trusted user CA key.

    When you configure this statement, the device adds the user CA public key to the /var/etc/ssh_trusted_user_ca.pub file. The Junos device uses the user CA public key to verify the user certificate during SSH session establishment.

Generate the User Certificate

To generate the SSH certificate for the NETCONF client:

  1. On the client NMS, generate an SSH key pair for the user.

    For example:

  2. Copy the user's public key to the CA server that has the CA signing keys, if the devices are different.

  3. Generate the user certificate.

    Use the user CA private key to sign the user's public key, and specify the list of authorized principals (users) that can access the Junos device using this certificate.

    The following command uses the CA private key stored in user_ca to sign the user's public key stored in id_rsa.pub. The certificate is valid for two principals: lab and netconf-user.

  4. Verify that the user certificate is created.

    For the previous step, the command creates the id_rsa-cert.pub file.

  5. Copy the user certificate to the network management system, if the devices are different.

  6. Ensure the user certificate file owner and permissions are correct.

  7. Add the SSH key and certificate identities to the ssh-agent application, if they are not added automatically. For example:

Generate the Host Certificate

The Junos device stores SSH keys in the /etc/ssh directory. To generate the host certificate, first copy the host's public key to the CA server, and then use the host CA private key to sign the host public key.

  1. On the Junos device, verify the host public keys.

  2. Copy the Junos device's public key to the CA server that has the CA signing keys.

  3. Generate the host certificate.

    Use the host CA private key to sign the host's public key, and specify the -h option to create a host certificate.

    The following command uses the CA private key stored in host_ca to sign the host's public key stored in ssh_host_rsa_key.pub.

  4. Verify that the host certificate is created.

    For the previous step, the command creates the ssh_host_rsa_key-cert.pub file.

  5. Copy the host certificate to the Junos device.

    For example:

  6. On the Junos device, configure the host certificate.

    When you configure this statement, the device adds the host certificate to the /var/etc/ssh_host_ca.pub file.

Configure the Authorized Principals

User certificates can be tied to specific users, or principals. Junos devices require that the user certificate specify one or more authorized principals. You must also configure authorized principals on the Junos device. The Junos device authenticates the certificate if at least one of the authorized principals configured on the device matches an authorized principal in the certificate.

You can configure the list of authorized principals using several methods. You can load a file that contains the list of authorized principals, each on a separate line. You can also configure the authorized principal list directly in the configuration.

To configure the authorized principals:

  1. (Optional) Create the authorized principals file and copy it to the Junos device.

  2. Configure the authorized principals that can access the system using SSH certificates.

    • To load a file containing the authorized principals, configure the authorized-principals-file statement and specify the path of the file to load.

      For example:

    • To configure one or more authorized principals directly in the configuration, use the authorized-principals statement and specify a principal name or a list of principal names.

      For example:

  3. Commit the configuration.

    When you configure authorized principals, the device adds the list of authorized principals to the /var/etc/ssh_authorized_principals file.

Enable the NETCONF Service

To configure the NETCONF service for NETCONF Call Home on the Junos device:
  1. Enable the NETCONF service on either the default NETCONF port (830) or a user-defined port.

    • To use the default NETCONF port (830), do not specify a port number.

    • To use a specific port, configure the port number.

      The port can range from 1 through 65535, however, you should avoid configuring access on a port that is normally assigned for another service .

  2. Configure RFC-compliant NETCONF sessions.
  3. Configure YANG-compliant NETCONF sessions.
  4. Commit the configuration:

Configure the Junos Device to Connect to the NETCONF Call Home Client

In a NETCONF call home scenario, the roles of the TCP server and client are reversed. You configure the Junos device to initiate, establish, and maintain a connection with a predefined set of network management systems. NETCONF Call Home uses outbound SSH to connect to the specified NETCONF clients.

Before you begin:

  • If you use SSH certificates for authentication, configure the user CA certificates, the host certificate, and the authorized principals.

Note:

The NETCONF call home client configuration registers the SSH certificate configuration at the time that you commit the client configuration. You must configure the host certificate and at least one user CA certificate and one authorized principal at the time that you commit the client configuration. If you add these initial values later, you must deactivate and commit the client configuration and then activate and commit the client configuration for the values to take effect. If the initial values are configured when you first activate the client configuration, then the client configuration will automatically register any updates to the existing values.

To configure a NETCONF Call Home client on the Junos device:

  1. At the [edit system services ssh] hierarchy level, set the SSH version to v2.
  2. Navigate to the outbound SSH client hierarchy, and define an identifier that uniquely identifies the NETCONF Call Home client.

    For example:

  3. Configure the hostname or the IPv4 or IPv6 address for the NETCONF client. Additionally, specify the port on which the NETCONF client (acting as the TCP server) is listening for connection requests.

    For example:

  4. Define the device identifier, which is a user-defined string that identifies the Junos device to the client during the initiation sequence.

    For example:

  5. Define the method used to reestablish a disconnected outbound SSH connection as sticky or in-order.
  6. Configure the NETCONF service for the session.
  7. (Optional) Configure the Junos device to send keepalive messages to the management server.

    For example, the following configuration sends a keepalive signal every 15 seconds (the default), and terminates the SSH connection after sending 3 messages (the default) that do not receive a response.

  8. (Optional) Configure the secret statement if you want pass the device's public key to the management server during session initialization.

    When you configure this statement, the device passes its public key along with a SHA1 hash derived in part from the secret statement to the management server during session initialization. The client application can use the shared secret and hash to verify whether the presented host key is from the device identified by the device-id statement.

  9. Repeat the preceding steps for each NETCONF Call Home client that will manage the Junos device.
  10. Commit the configuration.

After you configure the device to connect to the NETCONF Call Home client and commit the configuration, the device attempts to initiate a TCP/IP connection with the client. The device continues to create this connection until successful or until the NETCONF call home client configuration is deleted or deactivated.

Each time the Junos device establishes an outbound SSH connection, it sends an initiation sequence that identifies the device to the client. Within this transmission is the value of device-id. When you do not configure the secret statement, the initiation sequence is:

If you configure the secret statement, the initiation sequence includes the Junos device's public key, and a SHA1 hash derived in part from the secret statement. The client can compute the expected hash value and compare it to the HMAC value to verify that the presented host key is from the device identified by the device-id statement.

The client authenticates the Junos device by validating the presented host key or certificate. Similarly, the NETCONF server authenticates the client. The server first checks certificate-based authentication, then key-based authentication, and finally password-based authentication. After the SSH session is established, the client starts the NETCONF session.