SSHServer is migrated from SSH toolkit to OpenSSH, where the SSH server is added as part of the exsshd process. ExtremeXOS 21.1 supports SSH protocol version 2 from OpenSSH. Although the SSH server is added to exsshd, the key generation is not performed by exsshd. This is done separately by another module from OpenSSH, ssh-keyGen, which is involed from exsshd. The generated key is stored in /etc/ssh/ssh_host_dsa_key and /etc/ssh/ssh_host_dsa_key.pub. The same format is used for any keys that are imported to OpenSSH.
Print
this page
Email this topic
Feedback
View PDF
Download EPUB
-----BEGIN DSA PRIVATE KEY-----
MIIBugIBAAKBgQDMappaEi9ZRflK6PdkqbcUeHMyjykO+DdN8KH3opRIBW8a6ABz
OjLZJolWcMza3tw8u6VcALcqQzNDIvhZn7vJV7W256feojr/EXK/mt25NlzEpp+s
/49cHI+EW3T+Pp+WFj13VbNAFQZN54K35acnJrs08aGuKJeFWalRkzyBPwIVALuG
cOzg+/9DN8sl6YuCbPkvj0SjAoGAdjO+yYY06pdGqgGbmLGHC7xyav4cFgpo8Ria
q6ZXfs18E5Z0iHzdUhCgpMPFo7IyQTgZAQ+vUmwZXeH/aVVuQ/sAqOJG+VtGPoNf
3+hVE/ngu7TfSbS+ujVfmRZsQCD4pU8pYIJraRSf46gevTGdNZTBVarpxDq/kM15
IDF2+1YCgYBJ2Dcji6HkpbN2souTz1tXMxjcIQGaRc3k8wgtnsAiYxy13DolbtVF
xRSEalrDfaQ8T0F+cqpcYGmgpfUgKPnInGD7ygVUP7Ya5/fLXXdnckk77f0q7+id
2RT3lq8lzUMGR8b0aQxj8lCt1uCPfwsZ+PP5wArQHT2Uq0EfTrfBbgIUPk4Tffl8
+3X7nye4Iga7HbfDmys=
-----END DSA PRIVATE KEY-----
ssh-dss AAAAB3NzaC1kc3MAAACBAMxqmloSL1lF+Uro92SptxR4czKPKQ74N03wofeilEgFbxroAHM6MtkmiVZwzNre3 Dy7pVwAtypDM0Mi+Fmfu8lXtbbnp96iOv8Rcr+a3bk2XMSmn6z/j1wcj4RbdP4+n5YWPXdVs0AVBk3ngrflpycmu zTxoa4ol4VZqVGTPIE/AAAAFQC7hnDs4Pv/QzfLJemLgmz5L49EowAAAIB2M77JhjTql0aqAZuYsYcLvHJq/hw WCmjxGJqrpld+zXwTlnSIfN1SEKCkw8WjsjJBOBkBD69SbBld4f9pVW5D+wCo4kb5W0Y+g1/f6FUT+eC7tN9Jt L66NV+ZFmxAIPilTylggmtpFJ/jqB69MZ01lMFVqunEOr+QzXkgMXb7VgAAAIBJ2Dcji6HkpbN2souTz1tXMxjcIQ GaRc3k8wgtnsAiYxy13DOlbtVFxRSEalrDfaQ8T0F+cqpcYGmgpfUgKPnInGD7ygVUP7Ya5/fLXXdnckk77f0q7+ id2RT3lq8lzUMGR8b0aQxj8lCt1uCPfwsZ+PP5wArQHT2Uq0EfTrfBbg==root@s-1
Once you enable SSH2 from the CLI, the existence of the dsa key is verified. If it is not available, ssh-keygen is invoked to generate a public and private DSA key pair of size 1024. 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, and are stored in /etc/ssh/authorized_keys. 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/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.