Configuring a NSH Proxy Server

The NSH Proxy Server can be used to restrict NSH access so that a NSH client must first authenticate to the BMC Server Automation (BSA) application server before connecting to the manged system. Direct connections from the NSH clients on the user's workstations is not allowed, and all NSH connections to the managed servers will come from the BMC Server Automation application server(s).  

In this example, we are going to:


NSH is automatically installed during the installation of the BMC Server Automation console. In this scenario we have just installed the BMC Server Automation Console (that has NSH by default).

Scenario Configurations

For this scenario we have:

  • BSA/NSH Proxy Server (BSA Application Server) 
  • BSA/NSH Proxy Client 
  • Managed Server


Configure the Network Shell (NSH) Proxy Service on the Application Server

Infrastructure Management

  1. From the BSA Client, connect to a BSA Application Server in the environment and open Infrastructure Management.
  2. Assuming this instance is an 'ALL' profile type, right-click the application server and select Edit.
  3. Set ProxySvcPort to 9842.

Configure the NSH client on the applications server to use this NSH proxy (optional)

This set is required if you are using Automation Principals. Otherwise, it is optional, as NSH connections coming from the Application Server would not need to go through the NSH proxy.

Modifying the secure file

Before making changes to the file, make a backup of the secure file. 


You can take a backup of a secure file (within rsc folder), as the following command will update this file.

  1. Run the following Command:

    secadmin -m default -p 5 -appserver_protocol ssoproxy -T encryption_only -e tls
  2. After running the above command appserver_protocol=ssoproxy entry will be available in secure file (in rsc folder). The file can also be directly edited in a text editor instead of using secadmin

Restart the Application Server Service

On the BSA applications server where changes were made, restart the Application Server Service.

Configure a managed server to accept connections from only the NSH Proxy.

On the managed server perform the following steps:

Updating the users file

Make sure that the nouser entry is available in the users file (of rsc folder) on the other machines where you want to access using an NSH command.  Typically the nouser entry will exist in the file if ACLs are being pushed from BSA.

Updating the exports file

In the exports file ensure you have only an entry for the BSA application server's host name or IP address and no other entries.

Confirming access restriction

From your NSH client system, open up a NSH window and run:

This indicates that there is no access from your NSH client system. 

Configure a NSH client on a client workstation to connect to a managed server through the NSH proxy

On a client workstation that has the BladeLogic GUI installed perform the following steps.

Modifying the secure file


You can take a backup of a secure file (of rsc folder), as the following command will update this file.

Run the following Command:

secadmin -m default -p 5 -auth_profile defaultProfile -appserver_protocol ssoproxy -T encryption_only -e tls

Creating an Authentication Profile

If the Authentication Profile defaultProfile does not exist, create it, either from the first screen of the BSA gui or with the blcred command

blcred authprofile -add -profile defaultProfile -host <APPSERVER>:<AUTH_SERVICE_PORT> -type <AUTH_TYPE>


  • APPSERVER is the application server hostname or IP address
  • AUTH_SERVICE_PORT is the port the authentication service is listening on (9840 by default)
  • AUTH_TYPE is the authentication type for the user login (eg SRP)

Getting credentials

There are two ways to get the credentials for use with the NSH Proxy

Via the GUI

After launching the BSA GUI, click on the Options>> button and ensure the Save Credential for this session box is checked.

Via blcred

blcred cred -acquire -profile defaultProfile

Verify Access to managed system

Now run the same agentinfo command you ran before and see the successful result.


Because of nouser entry in users file, the credential will not work for the user that is not present in users file (of rsc folder) on the machine you are running NSH on. For example, if you are taking credential with any RBAC user (user1) on any Target Server, then user1 entry must be available in its users file.


Do not forget to destroy the cache credential once you are done running nsh commands. The following image shows how to destroy (delete) a cache credential.

Was this page helpful? Yes No Submitting... Thank you