Obscuring Bash Script Credentials Using Jamf

Putting credentials directly into script is never a great idea, so we’ll take a look at how to safely handle those using Jamf.

In a couple of my previous posts I went over some Nessus scripts, and in those scripts I would place keys directly in there. Since the scripts will be fed through Jamf, there’s a safer way to handle that by utilizing Bash Positional Parameters.

Those previous scripts included this command:

1
2
3
4
5

sudo /Library/NessusAgent/run/sbin/nessuscli agent link \
--key=<INSERT_NESSUS_KEY> \
--host=<INSERT_NESSUS_HOST> \
--port=<INSERT_NESSUS_PORT> \
--groups=$group

A more secure way to handle this sensitive information would be:

1
2
3
4
5

sudo /Library/NessusAgent/run/sbin/nessuscli agent link \
--key=$4 \
--host=$5 \
--port=$6 \
--groups=$group

Then after assigning a script to a Jamf policy, we will insert the sensitive data into the correct Parameter Values as such:

Not only does this help protect secrets, it can also make script sharing a bit easier as we don’t have to worry about scrubbing every last thing.
The above image also answers the question, “Why are we starting at $4?, as opposed to $1-$3?”

For further context, let’s look at an example of using a positional parameter outside of Jamf.
Here we have a script that will take a dog breed as a positional parameter; aptly named dog_breed.sh:

1
2
3
4

#!/bin/sh
dog=$1
echo "My favorite dog breed is $dog!"

This is along the lines of what it should look like when we run this script:

./dog_breed.sh "Yorkie"
My favorite dog breed is Yorkie!

And we will want to use quotes if there’s a space in there:

./dog_breed.sh "Golden Retriever"
My favorite dog breed is Golden Retriever!

Expanding upon this; a $2 variable will accept a second parameter, $3 a third, so on and so forth.