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.
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.
See Also
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:
[edit system services] telnet { connection-limit limit; rate-limit limit; }
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:
[edit system services] ftp { connection-limit limit; rate-limit limit; }
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:
request system software add pasvftp://name.com/jinstall.tgz
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:
[edit system services] finger { connection-limit limit; rate-limit limit; }
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 sessionsrate-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:
[edit system services] ssh { authentication-order [method 1 method2...]; authorized-keys-command authorized-keys-command; authorized-keys-command-user authorized-keys-command-user; ciphers [ cipher-1 cipher-2 cipher-3 ...]; client-alive-count-max number; client-alive-interval seconds; connection-limit limit; fingerprint-hash (md5 | sha2-256); hostkey-algorithm (algorithm | no-algorithm); key-exchange [algorithm1 algorithm2...]; log-key-changes log-key-changes; macs [algorithm1 algorithm2...]; max-pre-authentication-packets number; max-sessions-per-connection number; no-challenge-response; no-password-authentication; no-passwords; no-public-keys; no-tcp-forwarding; port port-number; protocol-version [v2]; rate-limit number; rekey { data-limit bytes; time-limit minutes; } root-login (allow | deny | deny-password); sftp-server; } tcp-forwarding;
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)
Starting in Junos OS Release 19.4R1 and Junos OS
Release 17.4R3, you can disable either the SSH login password or the
challenge-response authentication using the no-password-authentication and no-challenge-response options at the [edit system
services ssh] hierarchy level.
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
- Configuring Incoming SFTP Connections
- Configuring the SSH Protocol Version
- Configuring the Client Alive Mechanism
- Configuring the SSH Fingerprint Hash Algorithm
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:
[edit system services ssh] root-login (allow | deny | deny-password);
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 Incoming SFTP Connections
SSH File Transfer Protocol (SFTP) is a network protocol that
provides file access, file transfer, and file management over any
reliable data stream. Starting
in Junos OS Release 19.1R1, we have globally disabled the incoming
SFTP connections by default. If desired, you can globally enable incoming
SFTP connections by configuring the statement sftp-server at the [edit system services ssh] hierarchy level. Prior to Junos OS Release 19.1R1, incoming SFTP connections were
globally enabled by default.
Only the incoming SFTP connections are disabled by default.
For example, given devices A and B (where device A is running 19.1R1),
you cannot connect through SFTP from B to A by default. However, you
can connect through SFTP from device B to device A, if you configure sftp-server on device A.
The incoming SFTP connections are disabled by default. To enable incoming SFTP connections:
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:
[edit system services ssh] protocol-version [ v2 ];
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).
[edit system services ssh] client-alive-count-max 5; client-alive-interval 20;
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:
[edit system services ssh] fingerprint-hash (md5 | sha2-256);
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>
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.
SRX100 |
SRX210 SRX220 |
SRX240 |
SRX300 SRX320 SRX340 |
SRX345 |
SRX1500 |
|---|---|---|---|---|---|
3 |
3 |
5 |
3 |
5 |
5 |
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.
Option |
Description |
|---|---|
|
Use an 8-bit data path. |
|
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. |
|
Open a Telnet session to the specified hostname or IP address. |
|
Force the Telnet session to an IPv4 destination. |
|
Open a Telnet session to a host on the specified interface. If you do not include this option, all interfaces are used. |
|
Suppress the display of symbolic names. |
|
Specify the port number or service name on the host. |
|
Use the specified routing instance for the Telnet session. |
|
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>
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.
SRX100 |
SRX210 SRX220 |
SRX240 |
SRX300 SRX320 SRX340 |
SRX345 |
SRX1500 |
|---|---|---|---|---|---|
3 |
3 |
5 |
3 |
5 |
5 |
Table 2 describes the ssh command options.
Option |
Description |
|---|---|
|
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. |
|
Open an SSH connection to the specified hostname or IP address. |
|
Force the SSH connection to an IPv4 destination. |
|
Open an SSH connection to a host on the specified interface. If you do not include this option, all interfaces are used. |
|
Use the specified routing instance for the SSH connection. |
|
Use the specified source address for the SSH connection. |
|
Force SSH to use version 1 for the connection. |
|
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:
- Configuring SSH Known Hosts
- Configuring Support for SCP File Transfer
- 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:
[edit security ssh-known-hosts]
host corporate-archive-server, ip-address {
dsa-key key;
}
host archive-server-url {
rsa-key key;
}
host server-with-ssh-version-1, ip-address {
rsa1-key key;
}
Host keys are one of the following:
dsa-key key—Base64 encoded Digital Signature Algorithm (DSA) key for SSH version 2.ecdsa-sha2-nistp256-keykey—Base64 encoded ECDSA-SHA2-NIST256 key.ecdsa-sha2-nistp384-keykey—Base64 encoded ECDSA-SHA2-NIST384 key.ecdsa-sha2-nistp521-keykey—Base64 encoded ECDSA-SHA2-NIST521 key.ed25519-keykey—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.
[edit system archival configuration]
archive-sites {
scp://username<:password>@host<:port>/url-path;
}
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.
user@host# set system archival configuration archive-sites “<scp-url-path>” The authenticity of host <my-archive-server (<server-ip-address>)> can’t be established. RSA key fingerprint is <ascii-text key>. Are you sure you want to continue connecting (yes/no)?
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.
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.
user@host# set security ssh-known-hosts fetch-from-server <hostname>
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.
user@host# set security ssh-known-hosts load-key-file /var/tmp/known-hosts
See Also
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.
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.
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.comaes128-ctraes192-ctraes256-ctraes128-gcm@openssh.comaes256-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-cbcaes192-cbcaes128-cbc3des-cbcblowfish-cbccast128-cbcarcfour256arcfour128arcfour
Junos OS Release 16.1 supports the following set of key-exchange methods by default:
curve25519-sha256ecdh-sha2-nistp256ecdh-sha2-nistp384ecdh-sha2-nistp521group-exchange-sha2dh-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-sha1dh-group1-sha1
To configure the SSH service to support legacy cryptography:
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).
See Also
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.
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
- Sending the Public SSH Host Key to the Outbound SSH Client
- Configuring Keepalive Messages for Outbound SSH Connections
- Configuring a New Outbound SSH Connection
- Configuring the Outbound SSH Client to Accept NETCONF as an Available Service
- Configuring Outbound SSH Clients
- Configuring Routing Instances for Outbound SSH Clients
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:
[edit system services outbound-ssh client client-id] device-id device-id;
The initiation sequence when secret is not configured:
MSG-ID: DEVICE-CONN-INFO\r\n MSG-VER: V1\r\n DEVICE-ID: <device-id>\r\n
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:
[edit system services outbound-ssh client client-id] device-id device-id;
The initiation sequence when secret is not configured:
MSG-ID: DEVICE-CONN-INFO\r\n MSG-VER: V1\r\n DEVICE-ID: <device-id>\r\n
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.
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:
[edit system services outbound-ssh client client-id] secret password;
The following message is sent by the device when the secret attribute is configured:
MSG-ID: DEVICE-CONN-INFO\r\n MSG-VER: V1\r\n DEVICE-ID: <device-id>\r\n HOST-KEY: <public-hot-key>\r\n HMAC:<HMAC(pub-SSH-host-key, <secret>>)>\r\n
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:
[edit system services outbound-ssh client client-id]
keep-alive {
retry number;
timeout seconds;
}
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:
[edit system services outbound-ssh client-id] reconnect-strategy (sticky | in-order);
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:
[edit system services outbound-ssh client client-id]
services {
netconf;
}
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:
[edit system services outbound-ssh client client-id]
address address {
retry number;
timeout seconds;
port port-number;
}
Outbound SSH connections support IPv4 and IPv6 address formats.
Configuring Routing Instances for Outbound SSH Clients
(SRX Series and MX Series only) Starting in Junos OS Release
19.3R1, you can specify the name of the routing instance on which
the outbound SSH connectivity needs to be established by including
the routing-instance statement at the [edit system
services outbound-ssh] hierarchy level:
[edit system services outbound-ssh routing-instance routing-instance-name]
To use the management routing instance, first enable the mgmt_junos routing instance using the set system management-instance command.
To use any other routing instance, first configure the routing
instance at the [edit routing-instances] hierarchy.
If you do not specify a routing instance, your device will establish the outbound SSH connection using the default routing table.
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.
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.
See Also
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:
Example: Configure a Filter to Block Telnet and SSH Access
Requirements
Two devices running Junos OS with a shared network link. No special configuration beyond basic device initialization (management interface, remote access, user login accounts, etc.), is required before configuring this example. While not a strict requirement, console access to the R2 device is recommended.
Our content testing team has validated and updated this example.
Overview and Topology
In this example, you create an IPv4 stateless firewall filter that logs and rejects Telnet or SSH packets sent to the local Routing Engine, unless the packet originates from the 192.168.1.0/24 subnet. The filter is applied to the loopback interface to ensure that only traffic destined to the local device is impacted. You apply the filter in the input direction. An output filter is not used. As a result all locally generated traffic is allowed.
To match packets originating from a specific subnet or IP prefix, you use the
source-addressIPv4 match condition applied in the input direction.To match packets destined for the Telnet port and SSH ports, you use the
protocol tcpmatch condition combined with aport telnetandport sshIPv4 match conditions applied in the input direction.
Example Topology
Figure 1 shows the test topology for this example. The firewall filter is applied to the R2 device making it the device under test (DUT). The R1 and the R2 devices share a link that is assigned a subnet of 192.168.1.0/24. Both devices have loopback addresses assigned from the 192.168.255.0/24 prefix using a /32 subnet mask. Static routes provide reachability between loopback addresses as an interior gateway protocol is not configured in this basic example.
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.
By design the sample filter restricts Telnet and SSH access to R2 unless it originates from the shared subnet at R1. If you use SSH or Telnet to access the R2 device directly you will lose connectivity when the filter is applied. It’s recommended that you have console access when configuring this example. If needed you can use the R1 device as a jump host to launch an SSH session to R2 after the filter is applied. Alternatively, consider modifying the sample filter to also permit the IP subnet assigned to the machine you use to access the R2 device.
Perform the following tasks to configure this example:
- CLI Quick Configuration
- Configure the R1 Device
- Verify and Commit the Configuration at the R1 Device
- Configure the R2 Device
- Verify and Commit the Configuration at Device R2
CLI Quick Configuration
Quick Configuration for the R1 Device
To quickly configure the R1 device edit the following
commands as needed and paste them into the CLI at the [edit] hierarchy level. Be sure to issue a commit from configuration
mode to activate the changes.
set system host-name R1 set system services ssh root-login allow set interfaces ge-0/0/0 description "Link from R1 to R2" set interfaces ge-0/0/0 unit 0 family inet address 192.168.1.1/24 set interfaces lo0 unit 0 family inet address 192.168.255.1/32 set routing-options static route 192.168.255.2/32 next-hop 192.168.1.2
Quick Configuration for the R2 Device
To quickly configure the R2 device edit the following
commands as needed and paste them into the CLI at the [edit] hierarchy level. Be sure to issue a commit from configuration
mode to activate the changes.
Consider using commit-confirmed when making
changes that might impact remote access to your device. See Activating a Junos OS Configuration but Requiring Confirmation for details.
set system host-name R2 set system services ssh root-login allow set system services telnet set interfaces ge-0/0/0 description "Link from R2 to R1" set interfaces ge-0/0/0 unit 0 family inet address 192.168.1.2/24 set interfaces lo0 unit 0 family inet filter input local_acl set interfaces lo0 unit 0 family inet address 192.168.255.2/32 set firewall family inet filter local_acl term terminal_access from source-address 192.168.1.0/24 set firewall family inet filter local_acl term terminal_access from protocol tcp set firewall family inet filter local_acl term terminal_access from port ssh set firewall family inet filter local_acl term terminal_access from port telnet set firewall family inet filter local_acl term terminal_access then accept set firewall family inet filter local_acl term terminal_access_denied from protocol tcp set firewall family inet filter local_acl term terminal_access_denied from port ssh set firewall family inet filter local_acl term terminal_access_denied from port telnet set firewall family inet filter local_acl term terminal_access_denied then log set firewall family inet filter local_acl term terminal_access_denied then reject set firewall family inet filter local_acl term default-term then accept set routing-options static route 192.168.255.1/32 next-hop 192.168.1.1
Configure the R1 Device
Step-by-Step Procedure
Follow these steps to configure the R1 device:
Configure the interfaces:
[edit] user@R1# set interfaces ge-0/0/0 description "Link from R1 to R2" user@R1# set interfaces ge-0/0/0 unit 0 family inet address 192.168.1.1/24 user@R1# set interfaces lo0 unit 0 family inet address 192.168.255.1/32
Configure the host name and static route to the R2 device’s loopback address. You also configure Telnet and SSH access:
[edit] user@R1# set system host-name R1 user@R1# set system services ssh root-login allow user@R1# set system services telnet user@R1# set routing-options static route 192.168.255.2/32 next-hop 192.168.1.2
Verify and Commit the Configuration at the R1 Device
Step-by-Step Procedure
Follow the below steps to verify and commit your candidate configuration at the R1 device:
Confirm interface configuration with the
show interfacesconfiguration mode command. If the command output does not display the intended configuration, repeat the instructions in this example to correct the configuration.[edit] user@R1# show interfaces ge-0/0/0 { description "Link from R1 to R2"; unit 0 { family inet { address 192.168.1.1/24; } } } lo0 { unit 0 { family inet { address 192.168.255.1/32; } } }Verify the static route used to reach the R2 device’s loopback address and that SSH and Telnet access are enabled. Use the
show routing-optionsandshow system servicesconfiguration mode commands. If the command output does not display the intended configuration, repeat the instructions in this example to correct the configuration.[edit] user@R1# show routing-options static { route 192.168.255.2/32 next-hop 192.168.1.2; } user@R1# show system services ssh { root-login allow; } telnet;When satisfied with the configuration on the R1 device, commit your candidate configuration.
[edit] user@R1# commit
Configure the R2 Device
Step-by-Step Procedure
Follow the below steps to configure the R2 device. You begin by defining the stateless firewall filter that selectively blocks Telnet and SSH access:
Position yourself at the
edit firewall family inet filterlocal_acl hierarchy:[edit] user@R2# edit firewall family inet filter local_acl
Define the filter term terminal_access. This term permits Telnet and SSH from the specified source prefix(s):
[edit firewall family inet filter local_acl] user@R2# set term terminal_access from source-address 192.168.1.0/24 user@R2# set term terminal_access from protocol tcp user@R2# set term terminal_access from port ssh user@R2# set term terminal_access from port telnet user@R2# set term terminal_access then accept
Define the filter term terminal_access_denied. This term rejects SSH and Telnet from all other source addresses. This term is configured to log matches to the term, and to generate an explicit Internet Control Message Protocol (ICMP) destination unreachable response back to the packet’s source. See Firewall Filter Logging Actions for details on filter logging options.
Tip:You can use the
discardaction to suppress generation of ICMP error messages back to the source. See Firewall Filter Terminating Actions for details.[edit firewall family inet filter local_acl] user@R2# set term terminal_access_denied from protocol tcp user@R2# set term terminal_access_denied from port ssh user@R2# set term terminal_access_denied from port telnet user@R2# set term terminal_access_denied then log user@R2# set term terminal_access_denied then reject user@R2# set term default-term then accept
Define the filter term default-term. This term accepts all other traffic. Recall that Junos OS stateless filters have an implicit deny term at their end. The default-term overrides this behavior by terminating the filter with an explicit accept action. This results in all other traffic being accepted by the filer.
[edit firewall family inet filter local_acl] user@R2# set term default-term then accept
Configure the loopback interface and apply the filter in the input direction:
[edit] user@R2# set interfaces lo0 unit 0 family inet filter input local_acl user@R2# set interfaces lo0 unit 0 family inet address 192.168.255.2/32
Configure the host name, the ge-0/0/0 interface, the static route to the R1 device’s loopback address, and enable remote access through SSH and Telnet:
[edit] user@R2# set system host-name R2 user@R2# set system services ssh root-login allow user@R2# set system services telnet user@R2# set interfaces ge-0/0/0 description "Link from R2 to R1" user@R2# set interfaces ge-0/0/0 unit 0 family inet address 192.168.1.2/24 user@R2# set routing-options static route 192.168.255.1/32 next-hop 192.168.1.1
Verify and Commit the Configuration at Device R2
Step-by-Step Procedure
Follow the below steps to verify and commit your candidate configuration at the R2 device:
Confirm the configuration of the stateless firewall filter with the
show firewallconfiguration mode command. If the command output does not display the intended configuration, repeat the instructions in this example to correct the configuration.[edit] user@R2# show firewall family inet { filter local_acl { term terminal_access { from { source-address { 192.168.1.0/24; } protocol tcp; port [ssh telnet]; } then accept; } term terminal_access_denied { from { protocol tcp; port [ssh telnet]; } then { log; reject; } } term default-term { then accept; } } }Confirm interface configuration and filter application with the
show interfacesconfiguration mode command. If the command output does not display the intended configuration, repeat the instructions in this example to correct the configuration.[edit] user@R2# show interfaces ge-0/0/0 { description "Link from R2 to R1"; unit 0 { family inet { address 192.168.1.2/24; } } } lo0 { unit 0 { family inet { filter { input local_acl; } address 192.168.255.2/32; } } }Verify the static route used to reach the loopback address of the R1 device and that Telnet and SSH access are enabled. Use the
show routing-optionsandshow system servicesconfiguration mode commands. If the command output does not display the intended configuration, repeat the instructions in this example to correct the configuration.[edit] user@R2# show routing-options static { route 192.168.255.1/32 next-hop 192.168.1.1; } user@R2# show system services ssh { root-login allow; } telnet;When satisfied with the configuration on the R2 device, commit your candidate configuration.
Tip:Consider using
commit-confirmedwhen making changes that might impact remote access to your device. See Activating a Junos OS Configuration but Requiring Confirmation for details.[edit] user@R2# commit
Verify the Stateless Firewall Filter
Confirm that the firewall filter to limit Telnet and SSH access is working properly.
Verify Accepted Packets
Purpose
Verify that the firewall filter correctly allows SSH and Telnet when the traffic is sourced from the 192.168.1.0/24 subnet.
Action
Clear the firewall log on your router or switch.
user@R2> clear firewall log
From a host at an IP address within the 192.168.1.0/24 subnet, use a
ssh 192.168.255.2command to verify that you can log in to the device using SSH from an allowed source address. 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. You will be prompted to save the SSH host key if this is the first SSH login as user between these devices.Note:By default the R1 device will source the SSH traffic from the egress interface used to reach the destination. As a result this traffic is sourced from the 192.168.1.1 address assigned to the R1 device’s ge-0/0/0 interface.
user@R1>ssh 192.168.255.2 Password: Last login: Wed Aug 19 09:23:58 2020 from 192.168.1.1 --- JUNOS 20.2R1.10 Kernel 64-bit JNPR-11.0-20200608.0016468_buil user@R2>
Logout out of the CLI at the R2 device to close the SSH session.
user@R2> exit logout Connection to 192.168.255.2 closed. user@R1>
From a host at an IP address within the 192.168.1.0/24 subnet, use the
telnet 192.168.255.2command to verify that you can log in to your router or switch using Telnet from an allowed source address. 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 192.168.255.2 Trying 192.168.255.2... Connected to 192.168.255.2. Escape character is '^]'. login: user Password: --- JUNOS 20.2R1.10 Kernel 64-bit JNPR-11.0-20200608.0016468_buil user@R2>
Logout out of the CLI to close the Telnet session to the R2 device.
user@R2:~ # exit Connection closed by foreign host. root@R1>
Use the
show firewall logcommand to verify that the firewall log buffer on the R2 device’s Packet Forwarding Engine (PFE) does not contain any entries with a source address in the 192.168.1.0/24 subnet.user@R2> show firewall log
Verify Logged and Rejected Packets
Purpose
Verify that the firewall filter correctly rejects SSH and Telnet traffic that does not originate from the 192.168.1.0/24 subnet.
Action
Clear the firewall log on your router or switch.
user@R2> clear firewall log
Generate SSH traffic sourced from the loopback address of the R1 device. The source address of this traffic is outside of the allowed 192.168.1.0/24 subnet. Use the
ssh 192.168.255.2 source 192.168.255.1command to verify that you cannot log in to the device using SSH from this source address. This packet should be rejected, and the packet header information should be logged in the firewall filter log buffer.user@R1 ssh 192.168.255.2 source 192.168.255.1 ssh: connect to host 192.168.255.2 port 22: Connection refused root@R1>
The output shows the SSH connection is rejected. This confirms the filter is generating an ICMP error message, and that it correctly blocks SSH traffic when sent from a disallowed source address.
Generate Telnet traffic sourced from the loopback address of the R1 device. The source address of this traffic is outside of the allowed 192.168.1.0/24 subnet. Use the
telnet 192.168.255.2 source 192.168.255.1command to verify that you cannot log in to the device using Telnet from this source address. 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@R1> telnet 192.168.255.2 source 192.168.255.1 Trying 192.168.255.2... telnet: connect to address 192.168.255.2: Connection refused telnet: Unable to connect to remote host
The output shows the Telnet connection is rejected. This confirms the filter is generating an ICMP error message, and that it correctly blocks Telnet traffic when sent from a disallowed source address.
Use the
show firewall logcommand to verify that the firewall log buffer on the R2 device contains entries showing packets with a source address of 192.168.255.1 have been rejected.user@R2> show firewall log Log : Time Filter Action Interface Protocol Src Addr Dest Addr 15:17:11 pfe R ge-0/0/0.0 TCP 192.168.255.1 192.168.255.2 15:12:04 pfe R ge-0/0/0.0 TCP 192.168.255.1 192.168.255.2
The output confirms that traffic from the 192.168.255.1 source address has matched the filter’s terminal_access_denied term. The
Actioncolumn displays anRto indicate these packets were rejected. The interface, transport protocol, and the source and destination addresses are also listed. These results confirm the firewall filter is working properly for this example.