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. 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 (SSH server daemon/process) 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. ExtremeXOS SSH server supports protocol version 2. If the client has a protocol version 1.99 or above, the same is 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-7.5p1 supports Diffie-Hellman group 1, 14, 16, and 18 as part of the key exchange algorithms (see Diffie-Hellman Overview). The minimal supported Diffie-Hellman group is 14 by default in Default mode, since group 1 is considered weaker. After the key exchange algorithm is agreed upon, the ciphers are exchanged and agreed upon. Openssh-7.5p1 supports the following ciphers and MACs:

Ciphers: 3des-cbc, blowfish-cbc, aes128-cbc, cast128-cbc, aes192-cbc, aes256-cbc, arcfour, rijndael-cbc@lysator.liu.se, aes128-ctr, aes192-ctr, aes256-ctr, arcfour256, arcfour128, chacha20-poly1305@openssh.com
MACs: hmac-md5-etm@openssh.com, hmac-sha1-etm@openssh.com, hmac-sha2-256-etm@openssh.com, hmac-sha2-512-etm@openssh.com, hmac-ripemd160-etm@openssh.com, hmac-sha1-96-etm@openssh.com, hmac-md5-96-etm@openssh.com, hmac-md5; hmac-sha1, hmac-sha2-256, hmac-sha2-512, hmac-ripemd160, hmac-ripemd160@openssh.com, hmac-sha1-96, hmac-md5-96

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.

SSH Client /Server Connection Steps

Upon disabling SSH using the command disable ssh2 , 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 3,600 seconds 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.

Published March 2020prev | next

Email this topic

Print this page Print this page

Leave feedback Feedback