Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Guide That Contains This Content
[+] Expand All
[-] Collapse All

    Secure System Administration with SSH Overview

    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 supported. Also, 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.


    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.

    Note: SSH user authentication through RADIUS or TACACS+ is supported only on the default router.


    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.


    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.

    Published: 2014-08-12