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.
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.
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.
Print
this page
Email this topic
Feedback
View PDF
Download EPUB