Using Touch ID on Macbook Pro for sudo Authentication

Full credit goes to Cabel Sasser (@cabel) on this one for sharing the original tip. I’m simply sharing it here and showing the process to prove the awesomeness of this capability.

If you run a MacBook Pro with the Touch ID option, you have already discovered the speed at which you can authenticate for a number of GUI-driven products. Running sudo in the command line does not give you that luxury, usually.

By making a small change

First, you have to edit the /etc/pam.d/sudo file with your editor of choice. It’s a read only file and you need admin privileges to do so. Oh the irony!

I’m going to use sudo vim /etc/pam.d/sudo to open up the file. This prompts me for credentials in the terminal session, as it should:

Add the following to the first line in the file after the comment:

auth sufficient pam_tid.so

You can space it out for consistency with the other lines:

Save the file. It’s read-only, so I have to use w! to save, and then exit back to the shell and close your terminal.

Launch a new terminal session so that you have no cached sudo session credentials and try a new sudo command such as sudo vim /etc/hosts and watch the magic happen:

This should be a nice time saver for you, especially when you use complex passwords…like you should 🙂




Resetting vSphere 6.x ESXi Account Lockouts via SSH

VMware vSphere has had a good security feature added since vSphere ESXi 6.0 to add a root account lockout for safety. After a number of failed login attempts, the server will trigger a lockout. This is a good safety measure for when you have public facing servers and is even important for internally exposed servers on your corporate network. We can’t always assume that it’s external bad actors who are the only ones attempting to breach your devices.

Using the vSphere web client shows us the settings which are used to define the lockout count and duration. The parameters under the Advanced settings are as follows:

Security.AccountLockFailures
Security.AccountUnlockTime

Resetting your Failed Login Attempts with pam_tally2

There is a rather simple but effective tool to help you do this. It’s called pam_tally2 and is baked in with your ESXi installation. The command line to clear the lockout status and reset the count to zero for an account is shown here with the root account as an example:

pam_tally2 --user root --reset

In order to gain access to do this, you will need to have SSH access or console access to your server. Console access could be at a physical or virtual console. For SSH access, you need to use SSH keys to make sure that you won’t fall victim to the lockouts for administrative users. In fact, this should be a standard practice. Setting up the SSH keys is relatively simple and is nicely documented in the Knowledge Base article Allowing SSH access to ESXi/ESX hosts with public/private key authentication (1002866)

https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1002866

Uploading a key can be done with the vifs command as shown here:

https://docs.vmware.com/en/VMware-vSphere/6.0/com.vmware.vsphere.security.doc/GUID-392ADDE9-FD3B-49A2-BF64-4ACBB60EB149.html

The real question will come as to why you have the interface exposed publicly. This is a deeper question that we have to make sure to ask ourselves at all times. It’s generally not recommended as you can imagine. Ensuring you always use complex passwords and 2-factor authentication is another layer which we will explore. Hopefully this quick tip to safely reset your accounts for login is a good first step.




Installing PowerCLI 6.5.x on Windows Server 2012 R2 after Find-Module Error

Now that PowerCLI is part of the PowerShell Gallery, you can install it using the native module installer…but there’s a catch. Windows Server 2012 R2 requires a couple of minor updates to get this process underway. You’ll know really quickly if you open up your PowerShell terminal or PowerShell ISE (as Administrator) and try the following command:

Find-Module -name VMware.PowerCLI

The issue is easily solved be deploying a more recent installer for the PackageManagement PowerShell Modules. Download the installer using this link and run the install:

https://www.microsoft.com/en-us/download/details.aspx?id=51451

Select the Download within the page once you’re there:

Choose the x64 version (assuming you’re running a 64-bit OS):

Run through the installation and accept the defaults. Nothing significant to worry about with this file as it’s a necessary update for what we need to do.

If you run the Find-Module command again, you’ll see a much better result. You’ll be prompted to update your NuGet components which are used to pull resources from the PowerShell Gallery. Accept the update and then we can keep going:

Time to get back to the issues. Just relaunch your PowerShell terminal or ISE as an Administrator. We are running as Administrator so that we install the module for all users of the server. If you only want to run for your user then run your PowerShell session as your regular user and add -scope CurrentUser to the Install-Module command. Run the following to install for all users:

Install-Module -name VMware.PowerCLI

Now we have to import the module into our session using the Import-Module -name VMware.PowerCLI command:

Just like that, you’re up to date and running the latest and greatest PowerCLI goodness. Happy scripting!




Getting Terraform Provisioning Parameters from the Packet.net API

Provisioning on Packet.net is super easy using Terraform. One of the tricks you will need to know up front is that for Terraform and for many other provisioning tools, you need to provide a minimum set of parameters to launch.

As a minimum, you need to provide these following parameters as shown in the Terraform docs for the Packet provisioner:

  • hostname – gotta name ’em all
  • project_id – you need to know, or create the project to launch into
  • facility – which location are you deploying into? (EWR1, SJC1, etc.)
  • plan – which node type?
  • billing_cycle – hourly or monthly
  • operating_system – which OS will the node run?

Some are simple to use because they are your criteria. We choose the hostname, and we choose the billing cycle as either a static choice of hourly or monthly. How can we get the other details about our deployment? You can gather some data using a browser such as browsing to your project and then pulling the project ID from the URL. That still leaves us in search of the plan type, operating_system, and facility.

For completeness, let’s learn how to simply gather all four items (operating system list, project ID, plan types, facility) from the Packet.net API.

You’ll need a terminal session, your API key to query the Packet.net API, and the JQ tool for parsing out JSON results into something a little more friendly.

Querying the API is as easy as sending your token to the API using the cURL command and selecting which entities you want to query. This is the basic framework:

curl -s -X GET -H 'X-Auth-Token: YOURAPITOKEN' 'https://api.packet.net/OBJECT'

Now we can dig into the four easy examples we have.

Finding the Packet.net Facility Name

The simple one-liner will pull a JSON result that gives you the locations and subsequent Facility name that you can use and then parses out just the location codes to use. If you remove the '.facilities[].code' portion of the command it will show you the full pretty-printed JSON results including the full facility descriptions.

curl -s -X GET -H 'X-Auth-Token: YOURAPITOKEN' 'https://api.packet.net/facilities' | jq '.facilities[].code'

Finding the Packet.net Project ID

You’ll want the full JSON result so you can choose from your active projects if you have more than one. Just drill into the JSON results and you can locate the id field:

curl -s -X GET -H 'X-Auth-Token: YOURAPITOKEN' 'https://api.packet.net/projects' | jq

Finding the Packet.net Plan Names

Plans don’t shift around too much, just like facilities. Here is the simple query to get all the plan names and match them to what node type you want to use:

curl -s -X GET -H 'X-Auth-Token: YOURAPITOKEN' 'https://api.packet.net/plans' | jq '.plans[].slug'

Finding the Packet.net Operating System Types

By now, you can guess where we are going wth the next one. Query the API, parse out the results, and provide the slugs for the Operating System names which we will use for Terraform and other provisioning tools which consume the Packet API.

curl -s -X GET -H 'X-Auth-Token: YOURAPITOKEN' 'https://api.packet.net/operating-systems' | jq '.operating_systems[].slug'

The result will give you all of the slug names that are usable as the operating_system parameter. In the case of vSphere 6.5, it happens to be vmware_esxi_6_5 which may not have been obvious if you were to try guessing it out.

Now you can take those easy JSON results and feed them into a Terraform file or you may also use these raw queries as part of other configuration management and provisioning solutions. Hope you find this helpful!

Also, you can sign up for Packet.net to kick the tires on this goodness and you can use VDM25 as a referral code to get a 25$ credit to use. Make sure you tell them DiscoPosse and the Virtual Design Master crew sent you!