SSH version 2 (SSHv2) protocol is a complete rewrite of the SSHv1 protocol. In SSHv2 the functions are divided among three layers:
SSH Transport Layer (SSH-TRANS)
The SSH Transport Layer manages the server authentication and provides the initial connection between the client and the server. After the connection is established, the Transport Layer provides a secure, full-duplex connection between the client and server.
SSH Authentication Protocol (SSH-AUTH)
The SSH Authentication Protocol runs on top of the SSH Transport Layer and authenticates the client-side user to the server. SSH-AUTH defines three authentication methods: public key, host-based, and password. SSH-AUTH provides a single authenticated tunnel for the SSH connection protocol.
SSH Connection Protocol (SSH-CONN)
The SSH Connection Protocol runs on top of the SSH Transport Layer and user authentication protocols. SSH-CONN provides interactive logon sessions, remote execution of commands, forwarded TCP/IP connections, and forwarded X11 connections. These services are multiplexed into the single encrypted tunnel provided by the SSH transport layer.
The following figure shows the three layers of the SSHv2 protocol.
The modular approach of SSHv2 improves on the security, performance, and portability of the SSHv1 protocol.
Important
The SSHv1 and SSHv2 protocols are not compatible. The switch does not support SSHv1.
The SSHv2 protocol supports the following security features:
Authentication. This feature determines, in a reliable way, the SSHv2 client. During the log on process, the SSHv2 client is queried for a digital proof of identity.
Supported authentications with the switch as a server for SSHv2, are: RSA, DSA, and passwords. Supported authentications with the switch as a client for SSHv2, are: DSA and passwords. The switch does not support RSA when the switch acts as a client.
When the switch acts as an SSH server, by default the switch allows a maximum of only four sessions, although it can accommodate up to eight sessions at a time. However, only one SSH public key encryption per access level is allowed at a time. For instance, if multiple SSH public key encryption clients need to connect to the server with the same access level, such as rwa, then the clients must connect to the server one-by-one as the switch only supports one public key per access level.
Encryption. The SSHv2 server uses encryption algorithms to scramble data and render it unintelligible except to the receiver.
Supported encryption and ciphers are: 3DES, AES128-cbc, AES192-cbc, AES256-cbc, AES128–ctr, AES192-ctr, AES256-ctr, MD5, secure hash algorithm 1 (SHA-1) and SHA-2.
Integrity. This feature guarantees that the data transmits from the sender to the receiver without alterations. If a third party captures and modifies the traffic, the SSHv2 server detects this alteration.
Note
SCP is supported for RWA users only. RW or R level will not work and the switch logs a message on the device.
You must use CLI to initially configure SSHv2. You can use Enterprise Device Manager (EDM) to change the SSHv2 configuration parameters. CLI is the user interface for SSHv2 configuration and use the console port to configure the SSHv2 parameters. Depending on the hardware platform, the console port displays as console or 10101.
Important
Do not enable SSHv2 secure mode using Configuration and Orchestration Manager (COM). If you enable SSHv2 secure mode, then the system disables Simple Network Management Protocol (SNMP). This locks you out of a COM session. Enable SSH secure mode using CLI or EDM.
SSHv2 secure mode is different from enhanced secure mode and hsecure. SSHv2 secure mode disables unsecure management protocols on the device such as FTP, rlogin, SNMP, Telnet, and TFTP. SSHv2 secure mode is enabled through the ssh secure command.
When you enable SSHv2 secure mode, the system disables FTP, remote login (rlogin), SNMPv1, SNMPv2, SNMPv3, Telnet and TFTP. After SSHv2 secure mode is enabled, you can choose to enable individual non-secure protocols. However, after you save the configuration and restart the system, the non-secure protocol is again disabled, even though it is shown as enabled in the configuration file. After you enable SSHv2 secure mode, you cannot enable non-secure protocols by disabling SSHv2 secure mode.
You can disable block-snmp after you enable SSHv2 secure mode, and you can connect again using COM.