Secure System Administration with SSH

The system supports the SSH protocol version 2 as a secure alternative to Telnet for system administration.

Note: Versions earlier than 2.0.12 of the SSH protocol client are not supported. The SSH server embedded within the router recognizes SSH clients that report an SSH protocol version of 1.99, with the expectation that such clients are compatible with SSH protocol version 2.0. Clients that report an SSH protocol version of 1.99 apparently do so to determine the protocol version supported by the server.

SSH provides the following major features:

• Server authentication through a Diffie-Hellman key exchange—Protects against hackers interjecting mimics to obtain your password. You can be confident that you are connected to your own router.
• User authentication—Ensures that the router is allowing connection from a permitted host and remote user.

  Note: Digital Signature Standard (DSS) public key user authentication for SSH is not supported. Only password type SSH user authentication is supported. RADIUS and TACACS+ password authentication are the only user authentication protocols currently supported. RADIUS authentication is enabled by default. If authentication is disabled, then all SSH clients that pass protocol negotiation are accepted.

• Data encryption and key-protected hashing—Provides a secure, trustable session to the upper-layer user interface. Encryption provides confidentiality by preventing unauthorized persons from listening in on management traffic. Encryption and hashing ensure data integrity to obstruct man-in-the-middle attacks, in which unauthorized persons access messages and modify them without detection.

Transport

The SSH transport layer handles algorithm negotiation between the server and client over TCP/IP. Negotiation begins when the SSH client and server send each other textual information that identifies their SSH version. If they both agree that the versions are compatible, the client and server exchange lists that specify the algorithms that they support for key exchange, encryption, data integrity through a message authentication code (MAC), and compression. Each party sends two lists. One list has the algorithms supported for transmission; the other has the algorithms supported for receipt. The algorithms are specified in order of preference in each list. The client and server use the algorithm for each process that matches the client’s highest preference and is supported by the server. If no intersection is found, the negotiation attempt fails and the connection is terminated.

If algorithm negotiation is successful, the server sends its public host key to the client for authentication so the client can be certain that it is connected to the intended host rather than to an imposter. The client compares the key to its host key database. The client authenticates the server if the key is found in the database. If the key is not present, then the client can accept or reject this new, unknown key depending on how you have configured the client. For more information, see Host Key Management.

When the client authenticates the server’s host key, it begins the transport key exchange process by sending the key data required by the negotiated set of algorithms. The server responds by sending its own key data set. If both sides agree that the keys are consistent and authentic, the keys are applied so that all subsequent messages between client and server are encrypted, authenticated, and compressed according to the negotiated algorithms.

User Authentication

User authentication begins after the transport keys are applied. The client typically asks the server which authentication methods it supports. The server responds with a list of supported methods with no preference.

The system software currently supports RADIUS and TACACS+ password authentication. RADIUS authentication is enabled by default. Based on the authentication protocol that a user enables, the RADIUS or TACACS+ server validates the username and password from its database. If user authentication is disabled, then all SSH clients that pass protocol negotiation are accepted.

Connection

The SSH connection layer creates the user session when the user is authenticated. The server waits for a connection request. The router currently supports only shell requests, which the server interprets as a request for entry into a CLI session. The server ignores any other requests, such as X11 or TCP/IP tunneling.

Key Management

The E Series router implementation of SSH provides for management of user keys and host keys.

User Key Management

Key administration is still under development for the server environment.

Host Key Management

You create a host key for the SSH server with the crypto key generate dss command. If a host key already exists, this command replaces it with a new key and terminates all ongoing SSH sessions. Any SSH clients that previously accepted the old host key reject the new key the next time the client and server connect. The client then typically instructs the end user to delete the locally cached host key and to try to connect again.

Caution: Use caution issuing the crypto key generate dss command from an SSH client. Issuing this command will terminate that SSH session; it will be the last command you send from that session.

The public half of the host key is sent from the server to the client as part of the transport layer negotiation. The client attempts to find a match for this key with one stored locally and assigned to the server. If the client does not find a match, it can accept or reject the key sent from the server. Refer to your client documentation for detailed information. You typically configure the client to do one of the following:

• Never accept an unknown key.
• Always accept an unknown key.
• Query the administrator before accepting an unknown key.

If you do not want the client ever to trust the server when it sends an unknown key, you must manually copy—using the copy command—the host key from each server to each intended client. This is the only way to be certain that each client has a local copy of the necessary keys for matching during negotiation.

If you configure the client to accept unknown keys—either automatically or with administrator approval—this acceptance policy applies only to the first time the client receives a key from a particular server. When the SSH client accepts a host key, it stores the key locally and uses it for all future comparisons with keys received from that host. If the client subsequently receives a different key—a new unknown—from that server, it is rejected.

You cannot configure an SSH client to accept a new key after it has accepted a key from an SSH server. You must delete the old key before a new key can be accepted.

Performance

Generating a host key is computationally intensive and can take up to several minutes depending on the load of the system. The system cannot accept any CLI inputs from that session while it is generating the key.

Encryption, data integrity validation, and compression are all computationally intensive. These features can affect router performance in the following ways:

• Reduce the effective baud rate compared with Telnet or the local CLI. Users are unlikely to notice this performance degradation because user interaction is inherently slow compared with other system operations.
• Increase the general load on the system CPU.

Security Concerns

You might be concerned about security with the current support of SSH for the following reasons:

• Only RADIUS and TACACS+ user authentication methods are supported. If you disable user authentication, all users are accepted if the client and server successfully complete negotiation.
• Because the load on the system CPU increases with use of SSH, you might be concerned about denial-of-service attacks. However, the forwarding engine takes care of this issue, because it limits the rate at which it sends packets to the system controller. A flood of packets from a packet generator does not cause problems regardless of whether SSH is enabled.

Before You Configure SSH

You must obtain and install a commercial SSH client on the host from which you want to administer the system. Versions earlier than 2.0.12 of the SSH client are not supported.

Determine your Telnet policy before you configure SSH on your system. Effective use of SSH implies that you should severely limit Telnet access to the system. To limit Telnet access, create access control lists that prevent almost all Telnet usage, permitting only trusted administrators to access the system through Telnet. For example, you might limit access to administrators who need to Telnet to the system from a remote host that does not have the SSH client installed.

You must install and configure a RADIUS server on a host machine before you configure SSH on your router. Refer to your RADIUS server documentation for information about choosing a host machine and installing the server software. You must also configure the RADIUS client on your router. See JunosE Broadband Access Configuration Guide for more information.

SSH Configuration Tasks

You configure SSH on individual virtual routers, rather than on the global system. To configure SSH:

1. Access the context of the virtual router.
2. Configure encryption.(Optional)
3. Configure user authentication, including connection parameters.
4. Configure message authentication.(Optional)
5. Enable SSH.
6. Display SSH to verify configuration.

Configuring Encryption

The embedded SSH server and external SSH client maintain separate lists of the encryption algorithms that each supports. Lists are kept for inbound and outbound algorithms. For the server:

• Inbound means the algorithms that the server supports for information coming in from a client.
• Outbound means the algorithms that the server supports for information it sends out to a client.

You must configure each list separately. By default, all of the supported encryption algorithms are available. You need to configure encryption only if you need to specifically remove or add any supported algorithm from the list. Refer to your SSH client documentation for details on configuring encryption on your client. The system supports the following SSH algorithms for encryption:

• 3des-cbc—A triple DES block cipher with 8-byte blocks and 24 bytes of key data. The first 8 bytes of the key data are used for the first encryption, the next 8 bytes for the decryption, and the following 8 bytes for the final encryption.
• blowfish-cbc—A block cipher with 8-byte blocks and 128-bit keys that provides strong encryption and is faster than DES.
• twofish-cbc—A block cipher with 16-byte blocks and 256-bit keys that is stronger and faster than Blowfish encryption.

Although it is not recommended, you can also specify none. In this case, the system does not perform encryption.

Configuring User Authentication

The router supports RADIUS and TACACS+ for user authentication. RADIUS authentication is enabled by default. You must have previously configured a RADIUS or a TACACS+ server on a host system and its respective client (RADIUS or TACACS+) on your system.

You can specify timeout and retry limits to control the SSH connection process. The limits apply only from the time the user first tries to connect until the user has been successfully authenticated. The timeout limits are independent of any limits configured for virtual terminals (vtys). The following limits are supported:

• User authentication protocol—SSH user authentication protocol enabled on the router.
• SSH timeout—Maximum time allowed for a user to be authenticated, starting from the receipt of the first SSH protocol packet.
• Authentication retry—Number of times a user can try to correct incorrect information—such as a bad password—in a given connection attempt.
• Sleep—Prevents a user that has exceeded the authentication retry limit from connecting from the same host within the specified period.

Configuring Message Authentication

The SSH server and SSH client maintain separate lists of the message authentication algorithms that each supports. Lists are kept for inbound and outbound algorithms. For the server, inbound means the algorithms that the server supports for information coming in from a client. For the server, outbound means the algorithms that the server supports for information it sends out to a client. You must configure each list separately. By default, all of the supported encryption algorithms are available. You need to configure encryption only if you need to specifically remove or add any supported algorithm from the list. The system supports the following SSH algorithms for hash function-based message authentication:

• hmac-sha1—Uses Secure Hash Algorithm 1 (SHA-1) to create a 160-bit message digest from which it generates the MAC.
• hmac-sha1-96—Uses the first 96 bits of the SHA-1 message digest to generate the MAC.
• hmac-md5—Uses MD5 hashing to create a 128-bit message digest from which it generates the MAC.

Although it is not recommended, you can also specify none. In this case, the system does not verify the integrity of the data.

Enabling and Disabling SSH

The SSH server daemon starts only if the server host key exists when the router boots. The host key resides in NVS and is persistent across system reboots. After it has started, the daemon listens for traffic on TCP port 22. The server daemon is disabled by default.

Displaying SSH Status

You can monitor the current state of the SSH server with the show ip ssh command.

Terminating an SSH Session

You can use the session identifier to terminate an SSH session.