By default, the user can connect directly to a Service Engine via SSH using the system’s admin credentials. If there is a security requirement to restrict SSH connection, it is possible to disable this access using the following CLI configuration:
1: Connect to the NSX ALB controller and gain shell access
|
1 2 3 4 5 |
admin@172-19-10-51:~$ shell Login: admin Password: [admin:172-19-10-51]: > |
2: Run the following commands to disable admin SSH access to Service Engine.
|
1 2 3 4 5 6 7 8 9 |
[admin:172-19-10-51]: > configure serviceengineproperties [admin:172-19-10-51]: seproperties> se_runtime_properties [admin:172-19-10-51]: seproperties:se_runtime_properties> no admin_ssh_enabled [admin:172-19-10-51]: seproperties:se_runtime_properties> save [admin:172-19-10-51]: seproperties> save |
Is restricting SSH enough from the security point of view? The answer is NO.
With direct SSH access to Service Engines disabled, it is still possible for a user with the “Super User” privilege to remotely access a Service Engine’s shell through a secure tunnel from the Controller using the attach serviceengine command from the ALB controller CLI.
This will automatically log in to the Service Engine using an internal user account (avidebuguser) via PKI authentication – the Super User does not need to know the default admin account credentials. The avidebuguser account also has passwordless sudoer privileges.
References
https://avinetworks.com/docs/20.1/how-to-ssh-to-avi-linux-cli-using-a-non-admin-user/
https://avinetworks.com/docs/20.1/ssh-access-for-super-user/
And that’s it for this post. I hope you enjoyed reading this post. Feel free to share this on social media if it is worth sharing.