Configuring SSH

You configure SSH on individual virtual routers, rather than on the global system. 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. To configure SSH:

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

This topic includes the following tasks:

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.

The following tasks show how to add, remove, and restore SSH algorithms for encryption:

To add the blowfish-cbc algorithm to the list of supported inbound algorithms, issue the ip ssh crypto client-to-server blowfish-cbc command in Global Configuration mode.
host1(config)#ip ssh crypto client-to-server blowfish-cbc
To remove the 3des-cbc algorithm from the list of supported outbound algorithms, issue the ip ssh crypto server-to-client no 3des-cbc command in Global Configuration mode.
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
host1(config)#ip ssh crypto server-to-client default 3des-cbc

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.
host1(config)#ip ssh user-authentication-protocol TACACS+
SSH timeout—Maximum time allowed for a user to be authenticated, starting from the receipt of the first SSH protocol packet.
host1(config)#ip ssh timeout 480
Authentication retry—Number of times a user can try to correct incorrect information—such as a bad password—in a given connection attempt.
host1(config)#ip ssh authentication-retries 3
Sleep—Prevents a user that has exceeded the authentication retry limit from connecting from the same host within the specified period.
host1(config)#ip ssh sleep 300

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.
host1(config)#ip ssh mac client-to-server hmac-sha1
hmac-sha1-96—Uses the first 96 bits of the SHA-1 message digest to generate the MAC.
host1(config)#ip ssh mac client-to-server hmac-sha1-96
hmac-md5—Uses MD5 hashing to create a 128-bit message digest from which it generates the MAC.
host1(config)#ip ssh mac server-to-client hmac-md5

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.

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

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

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 Setting Virtual Terminal Access Lists for information about using access control lists.

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.

To create the SSH server host key and enable the daemon, issue the crypto key generate dss command in Global Configuration mode.
host1(config)#crypto key generate dss

To remove the SSH server host key and stop the SSH daemon if it is running, issue the crypto key zeroize dss command in Global Configuration mode.

Note: When you perform a stateful SRP switchover operation on a device with a large number of virtual routers (VRs) and when SSH is configured on VRs other than the default, SSH can sometimes become disabled. This condition happens if SSH attempts to bind with a VR before the VR becomes reenabled after the restart. In this case, after stateful SRP switchover is completed, if you enter the crypto key zeroize dss command to disable the SSH server daemon, a message is displayed stating that the VR instance is not enabled and prompts you to retry after SSH is reenabled on that VR. After the VR instance is reenabled, you must manually reenable SSH either by accessing the console VTY or creating a Telnet session to the router by using the crypto key generate dss command.

host1(config)#crypto key zeroize dss

Note: 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. There is no no version

Terminating an SSH Session

You can use the session identifier to terminate an SSH session. Use the show ip ssh command to determine the session identifier for the session to terminate.

To terminate an active SSH session, issue the disconnect ssh command in Global Configuration mode.

host1(config)#cdisconnect 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.