JUNOSe 9.1.x System Basics Configuration Guide > Passwords and Security > Secure System Administration with SSH

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. RADIUS password authentication is the only method of user authentication currently supported. It is enabled by default. If RADIUS 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 client specifies a user authentication method. If the chosen method is supported by the server, the client then challenges the user—that is, the client prompts the user for a password or public-key pass phrase. The client sends the challenge response from the user and the username to the server. The server authenticates the user based on this response.

The system software currently supports only RADIUS password authentication, which is enabled by default. The RADIUS 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 user authentication is 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, Chapter 1, Configuring Remote Access 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.

ip ssh crypto

• Use to add an encryption algorithm to the specified support list for the SSH server.

Example 1—This example adds the blowfish-cbc algorithm to the list of supported inbound algorithms.

host1(config)#ip ssh crypto client-to-server blowfish-cbc

Example 2—This example removes the 3des-cbc algorithm from the list of supported outbound algorithms.

host1(config)#ip ssh crypto server-to-client no 3des-cbc

• The default version restores the specified list to the factory default, which includes all supported algorithms (3des-cbc, twofish-cbc, and blowfish-cbc). The default list does not include the none option.

Example

host1(config)#ip ssh crypto server-to-client default 3des-cbc

• If you do not specify a direction (client-to-server or server-to-client), the command applies the algorithm to both inbound and outbound lists.
• Use the no version to remove or exclude an algorithm from the specified list.

Configuring User Authentication

The router supports RADIUS for user authentication. RADIUS authentication is enabled by default. You must have previously configured a RADIUS server on a host machine and the RADIUS client 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:

• 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.

ip ssh authentication-retries

• Use to set the number of times that a user can retry a failed authentication, such as trying to correct a wrong password. The SSH server terminates the connection when the limit is exceeded.
• Specify an integer from 0–20.
• Example

host1(config)#ip ssh authentication-retries 3

• Use the no version to restore the default value, 20 retry attempts.

ip ssh disable-user-authentication

• Use to disable RADIUS password authentication. If you disable RADIUS authentication, all SSH clients that pass protocol negotiation are accepted.
• RADIUS authentication is enabled by default.
• Example

host1(config)#ip ssh disable-user-authentication

• Use the no version to restore RADIUS authentication.

ip ssh sleep

• Use to set a sleep period in seconds for users that have exceeded the authentication retry limit. Connection attempts from the user at the same host are denied until this period expires.
• Specify any nonnegative integer.
• Example

host1(config)#ip ssh sleep 300

• Use the no version to restore the default value, 600 seconds.

ip ssh timeout

• Use to set a timeout period in seconds. The SSH server terminates the connection if protocol negotiation—including user authentication—is not completed within this timeout.
• Specify an integer from 10–600.
• Example

host1(config)#ip ssh timeout 480

• Use the no version to restore the default value, 600 seconds.

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.

ip ssh mac

• Use to add a message authentication algorithm to the specified support list for the SSH server.

Example 1—This example adds the hmac-md5 algorithm to the list of supported outbound algorithms.

host1(config)#ip ssh mac server-to-client hmac-md5

• If you to not specify a direction (client-to-server or server-to-client), the command applies the algorithm to both inbound and outbound lists.
• The default version restores the specified list to the factory default, which includes all supported algorithms (hmac-md5, hmac-sha1, and hmac-sha1-96). The default list does not include the none option.
• Example 2—This example restores the hmac-sha1 algorithm to the list of supported inbound algorithms.

host1(config)#ip ssh mac client-to-server default hmac-sha1

• Use the no version to remove or exclude an algorithm from the specified list.

Example 3—This example removes the hmac-sha1 algorithm from the list of supported inbound algorithms.

host1(config)#ip ssh mac client-to-server no hmac-sha1

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.

crypto key dss

• Use the generate keyword to create the SSH server host key and enable the daemon.
• Example

host1(config)#crypto key generate dss

• Use the zeroize keyword to remove the SSH server host key and stop the SSH daemon if it is running. Issuing this command terminates any active client sessions. The next time the router boots after this command is issued, the SSH server daemon is not started.
• The command is not displayed by the show configuration command.
  

  NOTE: SSH can be enabled or disabled regardless of the state of the Telnet daemon. If SSH is enabled, use access control lists to limit access through Telnet. See Virtual Terminal Access Lists for information about using access control lists.

  
  
• Example

host1(config)#crypto key zeroize dss

• There is no no version.

Displaying SSH Status

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

show ip ssh

• Use to display the current state of the SSH server.
• Use the detail keyword to display the encryption and MAC algorithm lists for the client and server. For each active session, detail shows the version of SSH running on the client and the algorithms in use for encryption and message authentication.
• Field descriptions

• daemon status—Indicates whether the SSH server is enabled; if so, how long it has been up
• supported encryption, inbound—Encryption algorithms supported inbound from the client
• supported encryption, outbound—Encryption algorithms supported outbound to the client
• supported MAC, inbound—Message authentication code algorithms supported inbound from the client
• supported MAC outbound—Message authentication code algorithms supported outbound to the client
• connections since last system reset—Number of connections made through SSH since the last time the system was reset
• connections since daemon startup—Number of connections made since the SSH server was enabled
• active sessions—Number of SSH sessions currently active

• id—Session ID number
• username—Username for the remote user that initiated the session
• host—IP address of the remote client
• uptime (d:h:m:s)—Duration of the session
• client version—Version of the SSH software run by the remote client
• ciphers inbound/outbound—Encryption algorithms used by the client and the system for this session
• MAC inbound/outbound—Message authentication code algorithms used by the client and the system for this session

• Example

host1#show ip ssh detail

SSH Server version: SSH-2.0-2.0.12

daemon status: enabled, up since MON NOV 08 1999 14:38:19 UTC

supported encryption, inbound: 3des-cbc,blowfish-cbc,twofish-cbc

supported encryption, outbound: 3des-cbc,blowfish-cbc,twofish-cbc

supported MAC, inbound: hmac-sha1,hmac-sha1-96,hmac-md5

supported MAC, outbound: hmac-sha1,hmac-sha1-96,hmac-md5

connections since last system reset: 4 out of 4 attempts

connections since daemon startup:    4 out of 4 attempts

active sessions: 1

 3

 mcarr

 10.0.0.145

 0:00:00:19

 SSH-2.0-2.0.12 F-SECURE SSH

 3des-cbc/3des-cbc

 hmac-md5/hmac-md5



 

• To view failed connection attempts and other protocol errors logged at the error severity level, use the show log data command:

host1#show log data category ssh severity error

Terminating an SSH Session

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

disconnect ssh

• Use to terminate an active SSH session.
• Use the show ip ssh command to determine the session identifier for the session to terminate.
• Example

host1(config)#disconnect ssh 12

 NOTE: You can also use the clear line vty terminal command to terminate SSH sessions. In that case, use the show users command to determine the virtual terminal number to specify with the clear line vty terminal command.



 

• There is no no version.