SSH

Secure Shell (SSH) is a protocol that provides a secure, encrypted Telnet-like connection to a router. A connection is always initiated by the client (the user). Authentication takes places by one of the configured authentication methods (local, RADIUS, TACACS+, and LDAP). With authentication and encryption, SSH allows for a secure connection over an insecure network.

The SR OS allows the administrator to configure Secure Shell version 1 (SSHv1) and version 2 (SSHv2). SSHv1 and SSHv2 are different protocols and encrypt at different parts of the packets. SSHv2 does not use the same networking implementation that SSHv1 does and is considered a more secure, efficient, and portable version of SSH.

SSH runs on top of a transport layer (like TCP or IP), and provides authentication and encryption capabilities.

The SR OS has a global SSH server process to support inbound SSH, SFTP, NETCONF, and SCP sessions initiated by external client applications. This server process is separate from the SSH and SCP client commands on the routers which initiate outbound SSH and SCP sessions.

Inbound SSH, Telnet, and FTP sessions are counted separately and it is possible to set the limit for each type separately in the config>system>login-control menu, However there is a maximum total of 50 sessions for SSH and Telnet together. SCP, SFTP, and NETCONF sessions are counted as SSH sessions.

When the SSH server is enabled, an SSH security key is generated. Unless the preserve-key option is configured for SSH, the security key is only valid until the node is restarted or the SSH server is stopped and restarted. The key size is non-configurable and set to 2048 for SSHv2 RSA, and to 1024 for SSHv2 DSA and SSHv1 RSA1. Only SSHv2 RSA is supported in FIPS mode. When the server is enabled, all inbound SSH, SCP, sFTP, and NETCONF sessions will be accepted provided the session is properly authenticated.

When the global SSH server process is disabled, no inbound SSH, SCP, sFTP, or NETCONF sessions are accepted.

When using SCP to copy files from an external device to the file system, the SCP server will accept either forward slash (‟/”) or backslash (‟\”) characters to delimit directory and/or filenames. Similarly, the SCP client application can use either slash or backslash characters, but not all SCP clients treat backslash characters as equivalent to slash characters. In particular, UNIX systems will often times interpret the backslash character as an ‟escape” character which does not get transmitted to the SCP server. For example, a destination directory specified as ‟cf1:\dir1\file1” will be transmitted to the SCP server as ‟cf1:dir1file1” where the backslash escape characters are stripped by the SCP client system before transmission. On systems where the client treats the backslash like an ‟escape” character, a double backslash ‟\\” or the forward slash ‟/” can typically be used to properly delimit directories and the filename.

There are three pairs of configurable lists: cipher lists, MAC lists, and KEX lists. In each pair one list is dedicated to the SSH server and second to the SSH/SCP client. These can be configured for negotiation of the best compatible cipher, MAC, and KEX algorithm between the client and server. The lists can be created and managed under the security ssh menu. The client lists are used when the SR OS is acting as the SSH client and the server lists are used when the SR OS is acting as a server. The first algorithm matched on the lists between the client and server is the preferred algorithm for the session.

SSHv2 authentication methods supported by the SR OS are password, keyboard-interactive, and public key.

Note: SSHv1 is not supported when the node is running in FIPS-140-2 mode.