How do you control authentication into ncs_cli?

[allenc]

In order to securely give users access to ncs_cli, we set it as their shell as described in the ncs_cli man page:

ncs_cli can be invoked from the command line. If so, no authentication is done. The archetypical usage of ncs_cli is to use it as a login shell in /etc/passwd, in which case authentication is done by the login program.

This basically works, but we've experienced some issues with using ncs_cli as a shell:

• Users cannot use a terminal manager like GNU screen to manage their SSH sessions
• Users cannot easily access files that they save using the save pipe command
• Users cannot easily access other resources on the OS, such as log files
• Users cannot access supplemental command-line tools we created

Our ideal solution would be to give the operators a typical shell like /bin/bash. That way, they would be able to access OS-level resources and use screen to manage ncs_cli sessions. However, we do not see a secure way to do that. As stated in the manpage quote above, "no authentication is done" when using ncs_cli from the command line. If a user has the ability to run ncs_cli, they have the ability to run it as any user.

Is there a secure way to allow users to run ncs_cli from the command line?

[Dan.Sullivan]

Most customers actually ssh directly to NSO itself and the hosting VM or Linux instance. In that way, they are forced to authenticate properly to gain access to NSO.

-Dan

[allenc]

Hi Dan,

I had forgotten that you can SSH directly into NSO.  Are you saying that the typical setup is for users to SSH directly into NSO (e.g., on port 2024) for NSO CLI access and port 22 for OS-level access?  If so, how do you prevent the user from running ncs_cli -u from the OS command line and using another user's privileges?  

Regardless, that solution does not solve our main problem, which was the first issue I mentioned: that users cannot use a terminal manager like GNU screen or tmux to manage their NSO CLI sessions.  That is actually the biggest pain point we have. In our environment, due to security restrictions and other issues, it is not uncommon for SSH sessions to become disconnected unexpectedly. GNU screen would allow network operators to reconnect and continue where they left off in the case of a disconnection. This is particularly important when waiting for a long-running NSO operation to complete. For example, say we have a service validation action that takes 20 minutes to run. Without screen, if a user gets disconnected after 15 minutes, they have no way of reconnecting to that ncs_cli session and seeing the action's output.

-Allen

[mvolf]

I think it's imaginable that the login session would connect to user's existing screen/tmux session (or start a new one) and each new shell in screen would start ncs_cli with the correct credentials. And there are other options (with similar complexity), such as a jump server, physical or virtual, or maybe even just a Docker image running on the same physical box, that does not allow users to do anything else than start screen and connect to NSO - I don't assume network disconnections would affect local ssh.

But if you are fine with users having shell access on the system running NSO, then you can simply disallow ncs_cli altogether and let users start screen sessions and ssh to NSO locally as they please.

[lmanor]

Hello,

Please check out the 'IPC Ports' and 'Restricting Access to the IPC port' sections in the NSO Administration Guide to see how to limit ncs_cli access.  Perhaps this mechanism can be used to achieve the behavior that you desire.

-Larry