I had a question the other day on whether it was possible to enable shell access for Active Directory users when logging into the vCenter Server Appliance (VCSA) via SSH? The answer is yes and though this is documented here, it is not very clear whether this is only applicable to SSO-based users only. In any case, the process to enable this is pretty straight forward and simply requires two steps which I have outlined below.
Step 0 - Ensure that your VCSA and/or PSC is joined to Active Directory before proceeding to the next step. If not, take a look at the documentation here for more details.
Step 1 - Login to vSphere Web Client and under Administration->System Configuration->Nodes->Manage->Settings->Access, go ahead and enable boh SSH and bash shell options. The first setting turns on SSH to the VCSA and the second setting allows users (local, SSO and AD) to access the shell on the VCSA.
Step 2 - In the vSphere Web Client and under Administration->Single Sign-On->Users and Groups->Groups, select the SystemConfiguration.BaseShellAdministrators group and add either an AD User and/or Group that you wish to allow to access the shell.
Once you have completed the steps above, you can now SSH to your VCSA/PSC using the AD user (UPN format) that you had authorized earlier. In the example below, I am logging into one of my VCSA using user *protected email* and as you can see, I am placed into the appliance shell by default.
At this point I can access all the appliancesh commands just like I normally would if I had logged as a root or *protected email*.
If we wish to change to bash shell, we simply just type "shell" which will enable shell access, assuming you had performed Step 2.
One thing that I noticed is that the default home directory for the AD user is /var/lib/nobody and apparently that does not exists by default, so users end up in / directory by default after enabling shell access. I am not sure if this is also related, but the username shows up as nobody as you can see from the prompt. This is something I will share with Engineering to see if we can improve upon as I am sure most of you would rather see the user that is actually logged in.
The good news from an auditing and logging standpoint is that for operations that are logged, it does properly show the username even though the prompt is showing up as nobody.
For auditing SSH logins, you can take a look at /var/log/messages and here is a snippet when logging in over SSH with AD user:
2017-10-04T19:05:34.595761+00:00 vcenter65-3 sshd[24899]: Accepted keyboard-interactive/pam for *protected email* from 172.30.0.121 port 56999 ssh2 2017-10-04T19:05:34.596753+00:00 vcenter65-3 sshd[24899]: pam_unix(sshd:session): session opened for user *protected email* by (uid=0)
For auditing all appliance shell operations (which are logged by default), you can take a look at /var/log/vmware/applmgmt-audit/applmgmt-audit-syslog.log and below is a snippet when running the system.update.get command:
17-10-04T19:02:45.338210+00:00 info applmgmt-audit 2017-10-04T19:02:45.277: INFO ---API Input Details--- 17-10-04T19:03:04.027464+00:00 info applmgmt-audit 2017-10-04T19:03:04.277: INFO Authentication request -- "user:"*protected email*", action:"system.listMethods", result:"success" 17-10-04T19:03:04.041664+00:00 info applmgmt-audit 2017-10-04T19:03:04.277: INFO AuthenticationResult = { authenticated=True, userid=False username=*protected email*, role=superAdministrator, renew=False, auth_method=SSO } 17-10-04T19:03:04.043748+00:00 info applmgmt-audit 2017-10-04T19:03:04.277: INFO Authentication request -- "user:"*protected email*", action:"system.listMethods", result:"success" 17-10-04T19:03:04.044535+00:00 info applmgmt-audit 2017-10-04T19:03:04.277: INFO AuthenticationResult = { authenticated=True, userid=False username=*protected email*, role=superAdministrator, renew=False, auth_method=SSO } 17-10-04T19:03:04.058065+00:00 info applmgmt-audit 2017-10-04T19:03:04.277: INFO Authentication request -- "user:"*protected email*", action:"system.listMethods", result:"success" 17-10-04T19:03:04.059265+00:00 info applmgmt-audit 2017-10-04T19:03:04.277: INFO AuthenticationResult = { authenticated=True, userid=False username=*protected email*, role=superAdministrator, renew=False, auth_method=SSO } 17-10-04T19:03:04.076688+00:00 info applmgmt-audit 2017-10-04T19:03:04.277: INFO Authentication request -- "user:"*protected email*", action:"com.vmware.appliance.system.uptime.get", result:"success" 17-10-04T19:03:04.078043+00:00 info applmgmt-audit 2017-10-04T19:03:04.277: INFO AuthenticationResult = { authenticated=True, userid=False username=*protected email*, role=superAdministrator, renew=False, auth_method=SSO } 17-10-04T19:03:04.081941+00:00 info applmgmt-audit 2017-10-04T19:03:04.277: INFO Authorization Result: User=*protected email*, priv=ViewConfiguration, authorized=False 17-10-04T19:03:04.082454+00:00 info applmgmt-audit 2017-10-04T19:03:04.277: INFO Authorization Result: User=*protected email*, priv=ModifyLocalConf, authorized=True 17-10-04T19:03:04.083534+00:00 info applmgmt-audit 2017-10-04T19:03:04.277: INFO Authorization Result: User=*protected email*, priv=ModifyLocalConf, authorized=True 17-10-04T19:03:04.085034+00:00 info applmgmt-audit 2017-10-04T19:03:04.277: INFO ---API Input Details--- 17-10-04T19:03:04.085501+00:00 info applmgmt-audit 2017-10-04T19:03:04.277: INFO Function : com.vmware.appliance.system.uptime.get 17-10-04T19:03:04.086017+00:00 info applmgmt-audit 2017-10-04T19:03:04.277: INFO ---API Input Details---
For general shell usage, as noted earlier when you logged into the VCSA, it is mostly NOT logged. Having said that, depending on the tools you use, it may still be logged at the application layer which you can find in some of the logs. In general, this is an area that Engineering is working on to improve and providing more comprehensive auditing capabilities for ANY user that accessing the VCSA whether that is via the API and/or direct shell access. If there is any feedback or requests that you may have, feel free to leave a comment and I will be sure to forward this off to the PM and the Engineering teams.
Is it working with external PSC connected VC because I have tried both ext and embedded and working only in embedded
Hello William,
thank you for this article. I added our admin AD group to the mentioned group (it was already in the SSO Administrators group). However, I cannot log in to VCSA SSH using my domain user (format: *protected email*), though I can log in with root user. bash is set as default shell in my VCSA.
Do you have any ideas?
There is a known issue when using this with an external PSC and users part of lots of AD groups. AD users which are part of lots of AD groups are not able to login to the appliance when they are part of a high number of AD groups.
The issue is being investigated by engineering.
Thanks for sharing but this does not work for me. Surprisingly because it makes so much sense. I get an error
Could not chdir to home directory /var/lib/nobody: No such file or directory
[ERROR]: Failed to connect to service.
Use service-control command to manage applmgmt service
* List APIs: "help api list"
* List Plugins: "help pi list"
* Launch BASH: "shell"
Command> shell.set --enabled true
Unknown command: `shell.set'
Command> shell
Unable to authorize
I think version 7 will be a much improved version of 6.5. There are still a few rather annoying issues with 6.5
Update for vSphere 8 please! Thanks!