WilliamLam.com

  • About
    • About
    • Privacy
  • VMware Cloud
  • Tanzu
    • Application Modernization
    • Tanzu services
    • Tanzu Community Edition
    • Tanzu Kubernetes Grid
    • vSphere with Tanzu
  • Home Lab
  • Nested Virtualization
  • Apple

Enabling shell access for Active Directory users via SSH to vCenter Server Appliance (VCSA)

10.09.2017 by William Lam // 4 Comments

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.

[Read more...]

Categories // Automation, VCSA Tags // active directory, appliancesh, ssh, vcenter server appliance, vcsa

How to remotely run appliancesh & other shell commands on VCSA w/o requiring SSH?

02.25.2016 by William Lam // 9 Comments

In vSphere 6.0 Update 1, the vCenter Server Appliance (VCSA) has received a significant enhancement to its Virtual Machine Management Interface also known as VAMI for short. As the name suggests, this interface provides basic configuration, monitoring and management capabilities for the Virtual Appliance which can be consumed through either a UI using a web browser or from the appliancesh CLI running within the VCSA Shell.

vcenter-server-appliance-appliancesh-and-other-commands-without-ssh-0
When talking to customers, they love the fact that the VCSA is harden out of the box and things like SSH are disabled by default. However, one challenge today is that if you need to access the appliancesh interface, SSH still must be enabled or direct console access would be required which is not ideal from an automation as well as from a security standpoint. Although things like SNMP can be configured on the VCSA to help alleviate some of these challenges, it does not solve the problem of having programmatic and remote management access.

VMware Engineering is aware of this request and is working on exposing the VAMI capabilities as an API in a future release of vSphere. In the mean time, not all hope is lost and there is still a solution which does not require you to give up security to be able to operate and manage your VCSA. We can do so by leveraging one of my all time favorite features of the vSphere Platform which is the Guest Operations API which allows you perform guest operations (running commands, transferring files, etc) directly within the guestOS as if you were logged in. Valid guest credentials are still required and once authenticated, the operations are then proxied through VMware Tools. Networking is not even required which makes this a really handy feature for troubleshooting and can even extend into application level provisioning using a single API. I can not stress enough on how cool and underutilized this feature is and it still comes as a surprise when I tell customers that this is actually possible.

Customers can consume the Guest Operations API by consuming it through one of our many supported vSphere SDKs as I have shown here or you can also consume it through PowerCLI using the Invoke-VMSCript cmdlet. To demonstrate the power of the Guest Operations API with the VCSA, I will completely disable all remote access to the VCSA which includes Local Login, Bash Shell and SSH as shown in the screenshot below.

vcenter-server-appliance-appliancesh-and-other-commands-without-ssh-1
Here is an example of running a simple "echo" command using the vSphere SDK for Perl:

vcenter-server-appliance-appliancesh-and-other-commands-without-ssh-2
Note: You will notice that there is no output and that is because the standard output must be re-directed to a file and then downloaded back to your client. The PowerCLI's Invoke-VMScript does handle this for you and will return any standand output to the console. For more complex commands, I would recommend creating a script that contains the command and just running the script itself which you can then log locally or into a file.

Here is an example of running the "appliancesh" command using the Invoke-VMScript cmdlet:

Invoke-VMScript -ScriptText "echo 'VMware1!' | appliancesh help pi list
" -vm VCSA-No-SSH -GuestUser root -GuestPassword VMware1!

vcenter-server-appliance-appliancesh-and-other-commands-without-ssh-4
Here is an example of running the "cmsso-util" command using the Invoke-VMScript cmdlet:

Invoke-VMScript -ScriptText "export VMWARE_VAPI_HOME=/usr/lib/vmware-vapi
export VMWARE_RUN_FIRSTBOOTS=/bin/run-firstboot-scripts
export VMWARE_DATA_DIR=/storage
export VMWARE_INSTALL_PARAMETER=/bin/install-parameter
export VMWARE_LOG_DIR=/var/log
export VMWARE_OPENSSL_BIN=/usr/bin/openssl
export VMWARE_TOMCAT=/opt/vmware/vfabric-tc-server-standard/tomcat-7.0.55.A.RELEASE
export VMWARE_RUNTIME_DATA_DIR=/var
export VMWARE_PYTHON_PATH=/usr/lib/vmware/site-packages
export VMWARE_TMP_DIR=/var/tmp/vmware
export VMWARE_PERFCHARTS_COMPONENT=perfcharts
export VMWARE_PYTHON_MODULES_HOME=/usr/lib/vmware/site-packages/cis
export VMWARE_JAVA_WRAPPER=/bin/heapsize_wrapper.sh
export VMWARE_COMMON_JARS=/usr/lib/vmware/common-jars
export VMWARE_TCROOT=/opt/vmware/vfabric-tc-server-standard
export VMWARE_PYTHON_BIN=/opt/vmware/bin/python
export VMWARE_CLOUDVM_RAM_SIZE=/usr/sbin/cloudvm-ram-size
export VMWARE_VAPI_CFG_DIR=/etc/vmware/vmware-vapi
export VMWARE_CFG_DIR=/etc/vmware
cmsso-util --help
" -vm VCSA-No-SSH -GuestUser root -GuestPassword VMware1!

Note: The reason the additional "export" commands are required is that certain commands may rely on certain environmental variables to be setup. In the case of the cmsso-util command, there are several VMware environmental variables it uses. I decided to just export them all but you can selectively figure out which ones are truly needed.

vcenter-server-appliance-appliancesh-and-other-commands-without-ssh-4
As you can see from the examples above, I was able to successfully run both shell commands as well as the appliancesh without requiring SSH and even local login! This methods works whether you are connected to vCenter Server or ESXi host from vSphere API perspective.

UPDATE (06/06/19) - Example joining the VCSA to Active Directory using domainjoin-cli

Invoke-VMScript -ScriptText "echo 'VMware1!' | /opt/likewise/bin/domainjoin-cli join vmware.corp administrator
" -vm VCSA -GuestUser root -GuestPassword VMware1!

Categories // Automation, VCSA, vSphere 6.0 Tags // appliancesh, cmsso-util, invoke-vmscript, ssh, vcenter server appliance, vcsa, vcva, vSphere 6.0

Easily manage ESXi & VCSA SSH login banner & MOTD in vSphere 6.0

02.27.2015 by William Lam // 3 Comments

For customers who have a requirement to configure an SSH login banner and/or message of the day (MOTD) for ESXi or vCenter Server, this usually meant manually editing the /etc/issues (login banner) and /etc/motd (MOTD) configuration files. In vSphere 6.0, this has now been simplified by providing vSphere APIs to allow administrators to easily view and configure SSH login banner and MOTD for both ESXi and VCSA (this does not apply to vCenter Server for Windows).

For ESXi, there are two new ESXi Advanced properties called Config.Etc.issue and Config.Etc.motd and this can also be viewed and edited using the vSphere Web/C# Client as seen in the screenshot below:

esxi-issues-motd
For vCenter Server, there are also two new Advanced Options called etc.issue and etc.motd which can also be viewed and edited using the vSphere Web/C# Client as seen in the screenshot below:

vcsa-motd-issues

What's Displayed

The /etc/issues displays a banner during an SSH login session, this means that you will see the message during the login as highlighted in the screenshot below:

esxi-issues
The /etc/motd displays a banner after a successful SSH login as highlighted in the screenshot below:

esxi-motd

How to Automate

You can use both the vSphere API/CLI to modify the issues and motd configurations. In the examples below, I will be using PowerCLI to demonstrate retrieving and setting the two properties.

Retrieve /etc/issues for VCSA

Get-AdvancedSetting -Entity $vc -Name "etc.issue" | Format-List

Set /etc/issues for VCSA

$msg = "
beware
you
are
entering
the
house
of
Cormac
the
grey
"
Get-AdvancedSetting -Entity $vc -Name "etc.issue" | Set-AdvancedSetting -Value $msg

Retrieve /etc/motd for VCSA

Get-AdvancedSetting -Entity $vc -Name "etc.motd" | Format-List

Set /etc/motd for VCSA

Get-AdvancedSetting -Entity $vc -Name "etc.motd" | Set-AdvancedSetting -Value $msg

Retrieve /etc/issues for ESXi

Get-VmHostAdvancedConfiguration -Name "Config.Etc.issue"

Set /etc/issues for ESXi

$msg = "
beware
you
are
entering
the
house
of
Cormac
the
grey
"
Set-VMHostAdvancedConfiguration -Name "Config.Etc.issue" -Value $msg

Retrieve /etc/motd for ESXi

Get-VmHostAdvancedConfiguration -Name "Config.Etc.issue"

Set /etc/motd for ESXi

Set-VMHostAdvancedConfiguration -Name "Config.Etc.motd" -Value $msg

Categories // ESXi, VCSA, vSphere 6.0 Tags // issues, motd, ssh, vcsa, vcva, vSphere 6.0

  • 1
  • 2
  • 3
  • Next Page »

Search

Author

William Lam is a Senior Staff Solution Architect working in the VMware Cloud team within the Cloud Infrastructure Business Group (CIBG) at VMware. He focuses on Cloud Native technologies, Automation, Integration and Operation for the VMware Cloud based Software Defined Datacenters (SDDC)

Connect

  • Email
  • GitHub
  • LinkedIn
  • RSS
  • Twitter
  • Vimeo

Recent

  • Self-Contained & Automated VMware Cloud Foundation (VCF) deployment using new VLC Holodeck Toolkit 03/29/2023
  • ESXi configstorecli enhancement in vSphere 8.0 Update 1 03/28/2023
  • ESXi on Intel NUC 13 Pro (Arena Canyon) 03/27/2023
  • Quick Tip - Enabling ESXi Coredumps to be stored on USB 03/26/2023
  • How to disable the Efficiency Cores (E-cores) on an Intel NUC? 03/24/2023

Advertisment

Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here: Cookie Policy

Copyright WilliamLam.com © 2023

 

Loading Comments...