Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Remote Access Overview

 

You can access a router, switch, or security device remotely using DHCP, Finger, FTP, rlogin, SSH, and Telnet services and so on. This topic shows you how to configure remote access using Telnet, SSH, FTP, and Finger services. Read this topic for more information.

System Services Overview

For security reasons, remote access to the router is disabled by default. You must configure the router explicitly so that users on remote systems can access it. The router can be accessed from a remote system by means of the DHCP, finger, FTP, rlogin, SSH, and Telnet services. In addition, Junos XML protocol client applications can use Secure Sockets Layer (SSL) or the Junos XML protocol-specific clear-text service, among other services.

Note

To protect system resources, you can limit the number of simultaneous connections that a service accepts and the number of processes owned by a single user. If either limit is exceeded, connection attempts fail.

Configuring Telnet Service for Remote Access to a Router or Switch

To configure the router or switch to accept Telnet as an access service, include the telnet statement at the [edit system services] hierarchy level:

By default, the router or switch supports a limited number of simultaneous Telnet sessions and connection attempts per minute.

Optionally, you can include either or both of the following statements to change the defaults:

  • connection-limit limit—Maximum number of simultaneous connections per protocol (IPV4 and IPv6). The range is from 1 through 250. The default is 75. When you configure a connection limit, the limit is applicable to the number of telnet sessions per protocol (IPv4 and IPv6). For example, a connection limit of 10 allows 10 IPv6 telnet sessions and 10 IPv4 telnet sessions.

  • rate-limit limit—Maximum number of connection attempts accepted per minute (from 1 through 250). The default is 150. When you configure a rate limit, the limit is applicable to the number of connection attempts per protocol (IPv4 and IPv6). For example, a rate limit of 10 allows 10 IPv6 telnet session connection attempts per minute and 10 IPv4 telnet session connection attempts per minute.

You cannot include the telnet statement on devices that run the Junos-FIPS software. We recommend that you do not use Telnet in a Common Criteria environment.

See also

Configuring FTP Service for Remote Access to the Router or Switch

To configure the router or switch to accept FTP as an access service, include the ftp statement at the [edit system services] hierarchy level:

By default, the router or switch supports a limited number of simultaneous FTP sessions and connection attempts per minute. You can include either or both of the following statements to change the defaults:

  • connection-limit limit—Maximum number of simultaneous connections per protocol (IPV4 and IPv6). The range is a value from 1 through 250. The default is 75. When you configure a connection limit, the limit is applicable to the number of sessions per protocol (IPv4 and IPv6). For example, a connection limit of 10 allows 10 IPv6 FTP sessions and 10 IPv4 FTP sessions.

  • rate-limit limit—Maximum number of connection attempts accepted per minute (a value from 1 through 250). The default is 150.When you configure a rate limit, the limit is applicable to the number of connection attempts per protocol (IPv4 and IPv6). For example, a rate limit of 10 allows 10 IPv6 FTP session connection attempts and 10 IPv4 FTP session connection attempts.

You can use passive FTP to access devices that accept only passive FTP services. All commands and statements that use FTP also accept passive FTP. Include the ftp statement at the [edit system services] hierarchy level to use either active FTP or passive FTP.

To start a passive FTP session, use pasvftp (instead of ftp ) in the standard FTP format (ftp://destination). For example:

You cannot include the ftp statement on routers or switches that run the Junos-FIPS software. We recommend that you do not use the finger service in a Common Criteria environment.

Configuring Finger Service for Remote Access to the Router

To configure the router to accept finger as an access service, include the finger statement at the [edit system services] hierarchy level:

By default, the router supports a limited number of simultaneous finger sessions and connection attempts per minute. Optionally, you can include either or both of the following statements to change the defaults:

  • connection-limit limit—Maximum number of simultaneous connections per protocol (IPv4 and IPv6). The range is a value from 1 through 250. The default is 75. When you configure a connection limit, the limit is applicable to the number of sessions per protocol (IPv4 and IPv6). For example, a connection limit of 10 allows 10 IPv6 clear-text service sessions and 10 IPv4 clear-text service sessions

  • rate-limit limit—Maximum number of connection attempts accepted per minute (a value from 1 through 250). The default is 150. When you configure a rate limit, the limit is applicable to the number of connection attempts per protocol (IPv4 and IPv6). For example, a rate limit of 10 allows 10 IPv6 session connection attempts per minute and 10 IPv4 session connection attempts per minute.

You cannot include the finger statement on routers that run the Junos-FIPS software. We recommend that you do not use the finger service in a Common Criteria environment.

Configuring SSH Service for Remote Access to the Router or Switch

To configure the router or switch to accept SSH as an access service, include the ssh statement at the [edit system services] hierarchy level:

By default, the router or switch supports a limited number of simultaneous SSH sessions and connection attempts per minute. Use the following statements to change the defaults:

  • connection-limit limit—Maximum number of simultaneous connections per protocol (IPv4 and IPv6). The range is a value from 1 through 250. The default is 75. When you configure a connection limit, the limit is applicable to the number of SSH sessions per protocol (IPv4 and IPv6). For example, a connection limit of 10 allows 10 IPv6 SSH sessions and 10 IPv4 SSH sessions.

  • max-sessions-per-connection number—Include this statement to specify the maximum number of SSH sessions allowed per single SSH connection. This allows you to limit the number of cloned sessions tunneled within a single SSH connection. The default value is 10.

  • rate-limit limit—Maximum number of connection attempts accepted per minute (a value from 1 through 250). The default is 150. When you configure a rate limit, the limit is applicable to the number of connection attempts per protocol (IPv4 and IPv6). For example, a rate limit of 10 allows 10 IPv6 SSH session connection attempts per minute and 10 IPv4 SSH session connection attempts per minute.

  • data-limit—Data limit before renegotiating session keys (bytes)

  • time-limit—Time limit before renegotiating session keys (minutes)

By default, a user can create an SSH tunnel over a CLI session to a router running Junos OS via SSH. This type of tunnel could be used to forward TCP traffic, bypassing any firewall filters or access control lists allowing access to resources beyond the router. Use the no-tcp-forwarding option to prevent a user from creating an SSH tunnel to a router via SSH.

For information about other configuration settings, see the following topics:

Configuring the Root Login Through SSH

By default, users are allowed to log in to the router or switch as root through SSH when the authentication method does not require a password. To control user access through SSH, include the root-login statement at the [edit systems services ssh] hierarchy level:

allow—Allows users to log in to the router or switch as root through SSH.

deny—Disables users from logging in to the router or switch as root through SSH.

deny-password—Allows users to log in to the router or switch as root through SSH when the authentication method (for example, RSA) does not require a password.

The default is deny-password.

Configuring the SSH Protocol Version

By default, only version 2 of the SSH protocol is enabled.

To configure the router or switch to use version 2 of the SSH protocol, include the protocol-version statement and specify v2 at the [edit system services ssh] hierarchy level:

Systems in FIPS mode always use SSH protocol version v2.

Configuring the Client Alive Mechanism

The client alive mechanism is valuable when the client or server depends on knowing when a connection has become inactive. It differs from the standard keepalive mechanism because the client alive messages are sent through the encrypted channel. The client alive mechanism is not enabled at default. To enable it, configure the client-alive-count-max and client-alive-interval statements. This option applies to SSH protocol version 2 only.

In the following example, unresponsive SSH clients will be disconnected after approximately 100 seconds (20 x 5).

See also

Configuring the SSH Fingerprint Hash Algorithm

To configure the hash algorithm used by the SSH server when it displays key fingerprints, include the fingerprint-hash statement and specify md5 or sha2-256 at the [edit system services ssh] hierarchy level:

The md5 hash algorithm is unavailable on systems in FIPS mode.

See also

The telnet Command

You can use the CLI telnet command to open a Telnet session to a remote device:

user@host> telnet host <8bit> <bypass-routing> <inet> <interface interface-name> <no-resolve> <port port> <routing-instance routing-instance-name> <source address>
Note

On SRX100, SRX210, SRX220, SRX240, SRX300, SRX320, SRX340, SRX345, and SRX1500 devices, the maximum number of concurrent Telnet sessions is indicated in the following table. Platform support depends on the Junos OS release in your installation.

SRX210

SRX220

3

To exit the Telnet session and return to the Telnet command prompt, press Ctrl-].

To exit the Telnet session and return to the CLI command prompt, enter quit.

Table 1 describes the telnet command options.

Table 1: CLI telnet Command Options

Option

Description

8bit

Use an 8-bit data path.

bypass-routing

Bypass the routing tables and open a Telnet session only to hosts on directly attached interfaces. If the host is not on a directly attached interface, an error message is returned.

host

Open a Telnet session to the specified hostname or IP address.

inet

Force the Telnet session to an IPv4 destination.

interface source-interface

Open a Telnet session to a host on the specified interface. If you do not include this option, all interfaces are used.

no-resolve

Suppress the display of symbolic names.

port port

Specify the port number or service name on the host.

routing-instance routing-instance-name

Use the specified routing instance for the Telnet session.

source address

Use the specified source address for the Telnet session.

The ssh Command

You can use the CLI ssh command to use the secure shell (SSH) program to open a connection to a remote device:

user@host> ssh host <bypass-routing> <inet> <interface interface-name> <routing-instance routing-instance-name> <source address> <v1> <v2>
Note

On SRX100, SRX210, SRX220, SRX240, SRX300, SRX320, SRX340, SRX345, and SRX1500 devices, the maximum number of concurrent SSH sessions is indicated in the following table. Platform support depends on the Junos OS release in your installation.

SRX210

SRX220

3

Table 2 describes the ssh command options.

Table 2: CLI ssh Command Options

Option

Description

bypass-routing

Bypass the routing tables and open an SSH connection only to hosts on directly attached interfaces. If the host is not on a directly attached interface, an error message is returned.

host

Open an SSH connection to the specified hostname or IP address.

inet

Force the SSH connection to an IPv4 destination.

interface source-interface

Open an SSH connection to a host on the specified interface. If you do not include this option, all interfaces are used.

routing-instance routing-instance-name

Use the specified routing instance for the SSH connection.

source address

Use the specified source address for the SSH connection.

v1

Force SSH to use version 1 for the connection.

v2

Force SSH to use version 2 for the connection.

Configuring SSH Host Keys for Secure Copying of Data

Secure Shell (SSH) uses encryption algorithms to generate a host, server, and session key system that ensures secure data transfer. You can configure SSH host keys to support secure copy (SCP) as an alternative to FTP for the background transfer of data such as configuration archives and event logs. To configure SSH support for SCP, you must complete the following tasks:

  • Specify SSH known hosts by including hostnames and host key information in the Routing Engine configuration hierarchy.

  • Set an SCP URL to specify the host from which to receive data. Setting this attribute automatically retrieves SSH host key information from the SCP server.

  • Verify that the host key is authentic.

  • Accept the secure connection. Accepting this connection automatically stores host key information in the local host key database. Storing host key information in the configuration hierarchy automates the secure handshake and allows background data transfer using SCP.

Tasks to configure SSH host keys for secure copying of data are:

  1. Configuring SSH Known Hosts

  2. Configuring Support for SCP File Transfer

  3. Updating SSH Host Key Information

Configuring SSH Known Hosts

To configure SSH known hosts, include the host statement, and specify hostname and host key options for trusted servers at the [edit security ssh-known-hosts] hierarchy level:

Host keys are one of the following:

  • dsa-key key—Base64 encoded Digital Signature Algorithm (DSA) key for SSH version 2.

  • ecdsa-sha2-nistp256-key key—Base64 encoded ECDSA-SHA2-NIST256 key.

  • ecdsa-sha2-nistp384-key key—Base64 encoded ECDSA-SHA2-NIST384 key.

  • ecdsa-sha2-nistp521-key key—Base64 encoded ECDSA-SHA2-NIST521 key.

  • ed25519-key key—Base64 encoded ED25519 key.

  • rsa-key key—Base64 encoded public key algorithm that supports encryption and digital signatures for SSH version 1 and SSH version 2.

  • rsa1-key key—Base64 encoded RSA public key algorithm, which supports encryption and digital signatures for SSH version 1.

Starting in Junos OS Release 18.3R1, the ssh-dss and ssh-dsa hostkey algorithms are deprecated— rather than immediately removed—to provide backward compatibility and a chance to bring your configuration into compliance with the new configuration.

Configuring Support for SCP File Transfer

To configure a known host to support background SCP file transfers, include the archive-sites statement at the [edit system archival configuration] hierarchy level.

Note

When specifying a URL in a Junos OS statement using an IPv6 host address, you must enclose the entire URL in quotation marks (" ") and enclose the IPv6 host address in brackets ([ ]). For example, “scp://username<:password>@[host]<:port>/url-path”;

Setting the archive-sites statement to point to an SCP URL triggers automatic host key retrieval. At this point, Junos OS connects to the SCP host to fetch the SSH public key, displays the host key message digest or fingerprint as output to the console, and terminates the connection to the server.

To verify that the host key is authentic, compare this fingerprint with a fingerprint that you obtain from the same host using a trusted source. If the fingerprints are identical, accept the host key by entering yes at the prompt. The host key information is then stored in the Routing Engine configuration and supports background data transfers using SCP.

Updating SSH Host Key Information

Typically, SSH host key information is automatically retrieved when you set a URL attribute for SCP using the archival configuration archive-sites statement at the [edit system] hierarchy level. However, if you need to manually update the host key database, use one of the following methods.

  1. Retrieving Host Key Information Manually

  2. Importing Host Key Information from a File

Retrieving Host Key Information Manually

To manually retrieve SSH public host key information, use the fetch-from-server option with the set security ssh-known-hosts command. You must include a hostname attribute with the set security ssh-known-hosts fetch-from-server command to specify the host from which to retrieve the SSH public key.

Importing Host Key Information from a File

To manually import SSH host key information from the known-hosts file located at /var/tmp/known-hosts on the server, include the load-key-file option with the set security ssh-known-hosts command. You must include the path to the known-hosts file with the set security ssh-known-hosts load-key-file command to specify the location from which to import host key information.

Configuring the SSH Service to Support Legacy Cryptography

Starting in Junos OS Release 16.1, the SSH server in Junos OS is based on OpenSSH 7 and defaults to a more secure set of ciphers and key-exchange algorithms. OpenSSH 7 omits some legacy cryptography.

Note

Lack of support for legacy cryptography in devices causes Junos Space device discovery to fail. To work around this issue, configure the device to support the 3des-cbc or blowfish-cbc cipher, or both, and the dh-group1-sha1 key-exchange method. This issue does not affect devices running Junos OS with upgraded FreeBSD.

Note

See the OpenSSH 7 documentation at https://www.openssh.com/ for more information about these extensions.

Junos OS Release 16.1 supports the following set of ciphers by default:

  • chacha20-poly1305@openssh.com

  • aes128-ctr

  • aes192-ctr

  • aes256-ctr

  • aes128-gcm@openssh.com

  • aes256-gcm@openssh.com

In Junos OS Release 16.1, the following ciphers are not supported by default, but you can configure your device to support them. They are listed from the most secure to the least secure:

  • aes256-cbc

  • aes192-cbc

  • aes128-cbc

  • 3des-cbc

  • blowfish-cbc

  • cast128-cbc

  • arcfour256

  • arcfour128

  • arcfour

Junos OS Release 16.1 supports the following set of key-exchange methods by default:

  • curve25519-sha256

  • ecdh-sha2-nistp256

  • ecdh-sha2-nistp384

  • ecdh-sha2-nistp521

  • group-exchange-sha2

  • dh-group14-sha1

In Junos OS Release 16.1, the following key-exchange methods are not supported by default, but you can configure your device to support them:

  • group-exchange-sha1

  • dh-group1-sha1

To configure the SSH service to support legacy cryptography:

Note

By configuring an ordered set of ciphers, key-exchange methods, or message authentication codes (MACs), the newly defined set is applied to both server and client commands. Changes to the defaults affect the file copy command when you use Secure Copy Protocol (SCP).

  1. Add support for ciphers by using the set system services ssh ciphers [ cipher 1 cipher 2 ... ] command. We recommend that you add the ciphers to the end of the configuration list so that they are among the last options used. In the following example, the 3des-cbc and blowfish-cbc ciphers are added to the default set:
  2. Add support for key-exchange methods by using the set system services ssh key-exchange [ method 1 method 2 ... ] command. We recommend that you add the key-exchange methods to the end of the configuration list so that they are among the last options used. In the following example, the dh-group1-sha1 key-exchange method is added to the default set:
  3. Commit the configuration:

Configuring Outbound SSH Service

You can configure a device running the Junos OS to initiate a TCP/IP connection with a client management application that would be blocked if the client attempted to initiate the connection (for example, if the device is behind a firewall). The outbound-ssh command instructs the device to create a TCP/IP connection with the client management application and to forward the identity of the device. Once the connection is established, the management application acts as the client and initiates the SSH sequence, and the device acts as the server and authenticates the client.

Note

There is no initiation command with outbound SSH. Once outbound SSH is configured and committed, the device begins to initiate an outbound SSH connection based on the committed configuration. The device repeatedly attempts to create this connection until successful. If the connection between the device and the client management application is dropped, the device again attempts to create a new outbound SSH connection until successful. This connection is maintained until the outbound SSH stanza is removed from the configuration.

To configure the device for outbound SSH connections, include the outbound-ssh statement at the [edit system services] hierarchy level:

[edit system services outbound-ssh]

The following topics describe the tasks for configuring the outbound SSH service:

Configuring the Device Identifier for Outbound SSH Connections

Each time the device establishes an outbound SSH connection, it first sends an initiation sequence to the management client. This sequence identifies the device to the management client. Within this transmission is the value of device-id.

To configure the device identifier of the device, include the device-id statement at the [edit system services outbound-ssh client client-id] hierarchy level:

The initiation sequence when secret is not configured:

Sending the Public SSH Host Key to the Outbound SSH Client

Each time the router or switch establishes an outbound SSH connection, it first sends an initiation sequence to the management client. This sequence identifies the router or switch to the management client. Within this transmission is the value of device-id.

To configure the device identifier of the router or switch, include the device-id statement at the [edit system services outbound-ssh client client-id] hierarchy level:

The initiation sequence when secret is not configured:

During the initialization of an SSH connection, the client authenticates the identity of the device using the public SSH host key of the device. Therefore, before the client can initiate the SSH sequence, it needs the public SSH key of the device. When you configure the secret statement, the device passes its public SSH key as part of the outbound SSH connection initiation sequence.

When the secret statement is set and the device establishes an outbound SSH connection, the device communicates its device ID, its public SSH key, and an SHA1 hash derived in part from the secret statement. The value of the secret statement is shared between the device and the management client. The client uses the shared secret to authenticate the public SSH host key it is receiving to determine whether the public key is from the device identified by the device-id statement.

Using the secret statement to transport the public SSH host key is optional. You can manually transport and install the public key onto the client system.

Note

Including the secret statement means that the device sends its public SSH host key every time it establishes a connection to the client. It is then up to the client to decide what to do with the SSH host key if it already has one for that device. We recommend that you replace the client’s copy with the new key. Host keys can change for various reasons and by replacing the key each time a connection is established, you ensure that the client has the latest key.

To send the router’s or switch’s public SSH host key when the device connects to the client, include the secret statement at the [edit system services outbound-ssh client client-id] hierarchy level:

The following message is sent by the device when the secret attribute is configured:

Configuring Keepalive Messages for Outbound SSH Connections

Once the client application has the router’s or switch’s public SSH host key, it can then initiate the SSH sequence as if it had created the TCP/IP connection and can authenticate the device using its copy of the router’s or switch’s public host SSH key as part of that sequence. The device authenticates the client user through the mechanisms supported in the Junos OS (RSA/DSA public string or password authentication).

To enable the device to send SSH protocol keepalive messages to the client application, configure the keep-alive statement at the [edit system services outbound-ssh client client-id] hierarchy level:

Configuring a New Outbound SSH Connection

When disconnected, the device begins to initiate a new outbound SSH connection. To specify how the device reconnects to the server after a connection is dropped, include the reconnect-strategy statement at the [edit system services outbound-ssh client client-id] hierarchy level:

You can also specify the number of retry attempts and set the amount of time before the reconnection attempts stop. See Configuring Keepalive Messages for Outbound SSH Connections.

Configuring the Outbound SSH Client to Accept NETCONF as an Available Service

To configure the application to accept NETCONF as an available service, include the services netconf statement at the [edit system services outbound-ssh client client-id] hierarchy level:

Configuring Outbound SSH Clients

To configure the clients available for this outbound SSH connection, list each client with a separate address statement at the [edit system services outbound-ssh client client-id] hierarchy level:

Note

Outbound SSH connections support IPv4 and IPv6 address formats.

Configuring NETCONF-Over-SSH Connections on a Specified TCP Port

The Junos OS enables you to restrict incoming NETCONF connections to a specified TCP port without configuring a firewall. To configure the TCP port used for NETCONF-over-SSH connections, include the port statement at the [edit system services netconf ssh] hierarchy level. The configured port accepts only NETCONF-over-SSH sessions. Regular SSH session requests for this port are rejected.

You can either configure the default port 830 for NETCONF connections over SSH, as specified in RFC 4742, Using the NETCONF Configuration Protocol over Secure Shell (SSH), or configure any port from 1 through 65535.

Note
  • The default SSH port (22) continues to accept NETCONF sessions even with a configured NETCONF server port. To disable the SSH port from accepting NETCONF sessions, specify this in the login event script.

  • We do not recommend configuring the default ports for FTP (21) and Telnet (23) services for configuring NETCONF-over-SSH connections.

Configuring Password Retry Limits for Telnet and SSH Access

To prevent brute force and dictionary attacks, the device performs the following actions for Telnet or SSH sessions by default:

  • Disconnects a session after a maximum of 10 consecutive password retries.

  • After the second password retry, introduces a delay in multiples of 5 seconds between subsequent password retries.

    For example, the device introduces a delay of 5 seconds between the third and fourth password retry, a delay of 10 seconds between the fourth and fifth password retry, and so on.

  • Enforces a minimum session time of 20 seconds during which a session cannot be disconnected. Configuring the minimum session time prevents malicious users from disconnecting sessions before the password retry delay goes into effect, and attempting brute force and dictionary attacks with multiple logins.

You can configure the password retry limits for Telnet and SSH access. In this example, you configure the device to take the following actions for Telnet and SSH sessions:

  • Allow a maximum of four consecutive password retries before disconnecting a session.

  • Introduce a delay in multiples of 5 seconds between password retries that occur after the second password retry.

  • Enforce a minimum session time of 40 seconds during which a session cannot be disconnected.

To configure password retry limits for Telnet and SSH access:

  1. Set the maximum number of consecutive password retries before a Telnet or SSH or telnet session is disconnected. The default number is 10, but you can set a number from 1 through 10.
  2. Set the threshold number of password retries after which a delay is introduced between two consecutive password retries. The default number is 2, but you can specify a value from 1 through 3.
  3. Set the delay (in seconds) between consecutive password retries after the threshold number of password retries. The default delay is in multiples of 5 seconds, but you can specify a value from 5 through 10 seconds.
  4. Set the minimum length of time (in seconds) during which a Telnet or SSH session cannot be disconnected. The default is 20 seconds, but you can specify an interval from 20 through 60 seconds.
  5. If you are done configuring the device, enter commit from configuration mode.

Example: Configuring a Filter to Block Telnet and SSH Access

Requirements

You must have access to a remote host that has network connectivity with this device.

Overview

In this example, you create an IPv4 stateless firewall filter that logs and rejects Telnet or SSH access packets unless the packet is destined for or originates from the 192.168.1.0/24 subnet.

  • To match packets destined for or originating from the address 192.168.1.0/24 subnet, you use the source-address 192.168.1.0/24 IPv4 match condition.

  • To match packets destined for or originating from a TCP port, Telnet port, or SSH port, you use the protocol tcp, port telnet, and telnet ssh IPv4 match conditions.

Configuration

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode.

To configure this example, perform the following tasks:

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Configure the Stateless Firewall Filter

Step-by-Step Procedure

To configure the stateless firewall filter that selectively blocks Telnet and SSH access:

  1. Create the stateless firewall filter local_acl.

  2. Define the filter term terminal_access.

  3. Define the filter term terminal_access_denied.

Apply the Firewall Filter to the Loopback Interface

Step-by-Step Procedure

  • To apply the firewall filter to the loopback interface:

Confirm and Commit Your Candidate Configuration

Step-by-Step Procedure

To confirm and then commit your candidate configuration:

  1. Confirm the configuration of the stateless firewall filter by entering the show firewall configuration mode command. If the command output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

  2. Confirm the configuration of the interface by entering the show interfaces configuration mode command. If the command output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

  3. If you are done configuring the device, commit your candidate configuration.

Verification

Confirm that the configuration is working properly.

Verifying Accepted Packets

Purpose

Verify that the actions of the firewall filter terms are taken.

Action

  1. Clear the firewall log on your router or switch.
    user@myhost> clear firewall log
  2. From a host at an IP address within the 192.168.1.0/24 subnet, use the ssh hostname command to verify that you can log in to the device using only SSH. This packet should be accepted, and the packet header information for this packet should not be logged in the firewall filter log buffer in the Packet Forwarding Engine.
    user@host-A> ssh myhost
    % cli
  3. From a host at an IP address within the 192.168.1.0/24 subnet, use the telnet hostname command to verify that you can log in to your router or switch using only Telnet. This packet should be accepted, and the packet header information for this packet should not be logged in the firewall filter log buffer in the Packet Forwarding Engine.
    user@host-A> telnet myhost
    login: user
    % cli
  4. Use the show firewall log command to verify that the routing table on the device does not contain any entries with a source address in the 192.168.1.0/24 subnet.
    user@myhost> show firewall log

Verifying Logged and Rejected Packets

Purpose

Verify that the actions of the firewall filter terms are taken.

Action

  1. Clear the firewall log on your router or switch.
    user@myhost> clear firewall log
  2. From a host at an IP address outside of the 192.168.1.0/24 subnet, use the ssh hostname command to verify that you cannot log in to the device using only SSH. This packet should be rejected, and the packet header information for this packet should be logged in the firewall filter log buffer in the Packet Forwarding Engine.
    user@host-B ssh myhost
  3. From a host at an IP address outside of the 192.168.1.0/24 subnet, use the telnet hostname command to verify that you can log in to the device using only Telnet. This packet should be rejected, and the packet header information for this packet should be logged in the firewall filter log buffer in the PFE.
    user@host-B> telnet myhost
  4. Use the show firewall log command to verify that the routing table on the device does not contain any entries with a source address in the 192.168.1.0/24 subnet.
    user@myhost> show firewall log
Release History Table
Release
Description
Starting in Junos OS Release 18.3R1, the ssh-dss and ssh-dsa hostkey algorithms are deprecated— rather than immediately removed—to provide backward compatibility and a chance to bring your configuration into compliance with the new configuration.