Understanding SSH Server

A 2,048-bit RSA Host key for the SSH server on the ExtremeXOS device is generated.Once the key is generated, the SSH server is started and listens for connections. The configurations listed in /etc/ssh/sshd_config are used for configuring the ssh server. Password and public key authentication methods are supported.

The client‘s public keys are configurable through the CLI. A maximum of 100 keys can be created. A specific key can hold a maximum of 16 users, and a single user can be added to a maximum of 16 keys.

For password authentication, the configuration should be done in the AAA module, where an account must be created for the user, either as an admin or a user, and the corresponding password should be configured. The same will be used for validating the user, when exsshd contacts AAA for authenticating the user.

Upon receiving a connection, it will be first validated with ACL (Access Control List)/Policy, if configured. If the source-address from which the connection has been established, and is configured for a deny action in the acl, the connection is closed.

If the ACL permits the source-address of the client, the server proceeds with authentication steps. As part of authentication, the versions are exchanged between the client and the server. EXOS SSH server supports protocol version 2. If the client has a protocol version 1.99 or above, the same will be accepted. Otherwise the connection is rejected. Once the versions of both the ends are accepted, key exchange algorithms proposal of server and client are matched. Openssh-6.5p1 supports Diffie-Hellman group 1 and 14 as part of the key exchange algorithms. As per common criteria requirement, only group 14 is allowed, since group 1 is weaker. You can configure the minimal supported Diffie-Hellman group as 14 to avoid using the weaker group 1 in the SSH server. By default, both group 1 and 14 are supported. After the key exchange algorithm is agreed upon, the ciphers are exchanged and agreed upon. Openssh-6.5p1 supports the following ciphers:
  • 3des-cbc
  • aes128-cbc
  • aes192-cbc
  • aes256-cbc
  • aes128-ctr
  • aes192-ctr
  • aes256-ctr
  • arcfour128
  • arcfour256
  • arcfour
  • blowfish-cbc
  • cast128-cbc
The following macs are supported by openssh 6.5p1:
  • hmac-sha1
  • hmac-sha1-96
  • hmac-sha2-256
  • hmac-sha2-512
  • hmac-md5
  • hmac-md5-96
  • hmac-ripemd160
  • hmac-ripemd160@openssh.com
  • umac-64@openssh.com
  • umac-128@openssh.com
  • hmac-sha1-etm@openssh.com
  • hmac-sha1-96-etm@openssh.com
  • hmac-sha2-256-etm@openssh.com
  • hmac-sha2-512-etm@openssh.com
  • hmac-md5-etm@openssh.com
  • hmac-md5-96-etm@openssh.com
  • hmac-ripemd160-etm@openssh.com
  • umac-64-etm@openssh.com
  • umac-128-etm@openssh.com

After the key exchanges, the local authentication methods that are supported (public key and password authentication) are tried first. If there is a matching key or password, the AAA authentication will be tried out. Else, the user will be considered to be unknown, and the session will be terminated.

Below are the steps that are involved between the client and the server while establishing the connection.

Click to expand in new window
SSH Client /Server Connection Steps
../Graphics/establishing_ssh_client_server_connection.svg

Upon disabling the SSH daemon, the server stops listening for new connections, but the existing connections continue to be active. When you enable the SSH server again, the key is not regenerated by default. Specific sessions or all the sessions can be closed through clear session command through CLI. The sessions are closed once the idle-timeout expires. By default the idle timeout is 3600 for SSH. The same can be configured through the CLI. If the session is left idle for more than the configured/default idle-timeout value in seconds, then the session is closed by the server. The idle timeout will be on per session basis. In other words, the idle timeout that is configured when the session is established, will be the one used for that particular session. If the user changes the idle timeout after the session is established, that will not be reflected on the existing sessions, but will be used for new sessions.