Secure Shell Overview

The Secure Shell (SSH) security feature provides a secure encrypted communications method between a client and the switch providing data privacy and integrity that is an alternative to the unsecure Telnet protocol. Using SSH, the entire session is encrypted, including the transmission of user names and passwords, and negotiated between a client and server both configured with the SSH protocol. Telnet sessions are unsecure. All data is sent unencrypted. Use SSH instead of Telnet when the security of login and data transmission is a concern.

The S- K- and 7100-Series SSHv2 implementation includes:

• Data privacy
• Communication integrity

An SSH server resides on the S- K- or 7100-Series platform and listens for client connection requests. Once a request is authenticated, a secure connection is formed through which all subsequent traffic is sent. All traffic is encrypted across the secure channel, which ensures data integrity. This prevents someone from seeing clear text passwords or file content, as is possible with the Telnet application.

Once SSH has been enabled and the 7100-Series has at least one valid IP address, you can establish an SSH client session from any TCP/IP based node on the network, by using an application supporting SSH to connect to an IP address and entering your user name and password. Refer to the instructions included with your SSH application for information about establishing a session.

SSH is activated by enabling the SSH server on the device, using the set ssh enable command in any command mode.

Enabling the server automatically generates a host key for the server, used during the life of the client to server connection. The host key type can be set to either dsa or rsa. The host key type defaults to rsa.

There is one host key per device; every time an SSH client logs into a device it should see the same host key; if the host key is different, the SSH Client warns you that the host key has changed. The following is a sample warning when an SSH Client detects a new host key:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
67:c6:71:ff:e8:02:7c:ce:0f:0d:67:67:63:a8:2e:9c.
Please contact your system administrator.
Add correct host key in /home/documentation/doc1/.ssh/known_hosts to get rid of this message.
Offending key in /home/documentation/doc1/.ssh/known_hosts:24
RSA host key for 10.4.99.4 has changed and you have requested strict checking.
Host key verification failed.

The SSH server can be reinitialized. Reinitializing the server clears all current client to server connections. Reinitializing the server does not reinitialize the host key. Should you believe the host key has been compromised, or otherwise wish to change it, the host key can be reinitialized using the set ssh hostkey reinitialize command.

An SSH session to a remote host can be started using the ssh command.

Use the show ssh state command in any command mode to display whether SSH is currently enabled or disabled.