Execute Shell Scripts From any Directory

I previously mentioned that I use shell scripts to make my work more efficient. I used to keep scripts scattered around my home directory, but now keep them organized in a single directory. Feel free to skip the initial step below if you’re the disorganized type.

Step Zero

Put all scripts into the same directory. I keep mine in ~/bin. I used to use ~/.bin to keep them hidden from view, but found that I tended to forget about the directory and kept old scripts that I didn’t use anymore.

Step One

Make the script executable. Let’s say I have a script named “banana” that I want to be able to use from any directory on my machine:

Chmod +x banana

Now, banana is executable. I can verify the new permissions by running ls -l or by checking for the asterisk (*) after the script name:

banana*

Step Two

I add the bin directory to the known paths so that scripts there can be run from anywhere. I define the path in my ~/.bash_profile. The .bash_profile file may already have some paths defined already. If it does, the script directory can be added to the line. If it doesn’t, I add both the script directory and the current paths ($PATH) to be sure the new path(s) don’t override the old:

export PATH="~/bin:$PATH"

Although I could add multiple paths after the colon and add as many paths as I need in one line, I keep my .bash_profile readable by adding a separate export… line for each path. I have separate PATHs for Golang, Python, Git, etc, and I prefer to keep each on a separate line.

Advertisement

Update Homebrew on macOS With One Script

I use multiple Homebrew packages and I appreciate Homebrew’s built in package management, so each time I update Homebrew packages on my mac, I get tired of typing multiple commands, especially since I like to be thorough. I use brew update to update the formula and Homebrew itself, brew upgrade to update everything, brew cleanup to delete any unfinished downloads, and finally brew doctor to check for issues.

My initial thought was that I could just create a simple alias to run all four commands at once:

alias brewup='brew update; brew upgrade; brew cleanup; brew doctor'

I decided to improve on the idea and create a bash script that would run all the commands and echo messages back to me as it was running. I did it like this:

I used the printf command to tell me which part of the script is currently being executed, so if the script appears to be hanging I know how far it completed. I formatted the text to use a color that doesn’t appear elsewhere in my terminal’s color scheme so that I know that the outputted text is from my script rather than as a result of a Homebrew process.

Finally, I named the script brewup, stuck it in my ~/bin directory and made it executable from any directory:

chmod +x brewup

Now that the script is executable I can run the script no matter how far down I’m working in a nested directory. When I want to update my Homebrew packages, I can type a single word and let Homebrew update in one terminal window while I work on something else:

brewup

If you like what I did and want to save yourself some typing, you can get a copy of the script from my GitHub.

How to Manage Multiple SSH Key Pairs

Most developers will interact with resources that use SSH keys instead of passwords. I recently overheard someone say that he uses the same SSH key for all of his accounts, which is a bad idea from a security perspective. The more places a single key is authorized, the more valuable that key becomes. If that key gets compromised, more targets are put at risk. There are multiple situations where I use a different key pair:

  • Team resources that share the same key
  • IOT Devices
  • Older systems that don’t support the newest ed25519 encryption algorithm
  • Separate keys for each consulting client I have

When I initially started managing multiple SSH key/password combinations on my personal machine, I learned best practices from a variety of sources. I’m writing this information down in one place for the benefit of others. My current OS of choice is MacOS, but these instructions should work for any *nix system. Atlassian recommends users replace their SSH keys once a year for security. Following these steps will ensure that you can.

First: Generate a new key

Open terminal and navigate to ~/.ssh to generate a new SSH key:

ssh-keygen -t ed25519 -f ~/.ssh/key_name -C "name@example.com"

Here is what each flag means:

  • -t specifies the algorithm that makes the key.
  • -f specifies a custom name for the key (assuming you’re in the ~/.ssh directory), and an alternate location if it’s in the form of a path. The key_name is the name of the key. If you created SSH keys previously, ssh-keygen may ask you to rewrite another key, so I recommend choosing a key name that is specific as possible.
  • -C is an option to include a comment. It can be anything but is usually in the form user@host (who generated the key)

I always use a key name that is specific and makes sense to me. This makes key management easier in the long term. You should use a passphrase when prompted.

Second: Create known_hosts file

When you complete the first step two files are created: key_name and key_name.pub. The first is your private key and the second (with the .pub extension) is your public key.

Create a known_hosts file for each account you have because it makes diagnosing issues easier when you have multiple keys. Ideally the name of this file is similar enough to the key name that you aren’t confused later.

touch known_hosts_keyname

Third: Set up the config file

The config file sets options for each host. Create the config file if it doesn’t already exist and then open it for editing. I label each key for visual neatness and to avoid confusion as the list of keys gets longer over time. Create a comment using the # at the start of a line to label each host. The text in the picture below is available here to save you some typing.

Here is the breakdown of what each line means:

  • Host is a pattern matcher that is used to differentiate between these sets of configurations. Keep it the same as the HostName so it matches hosts in connections correctly without additional specification.
  • The URL on the HostName line is the base URL where the repository resides. For example, if you have a personal account on github with personal projects, the URL will be github.com.
  • User for git based systems will be git. The value of User will be different if you connect to something else (i.e. ec2-user for connecting to an Amazon AWS EC2 instance)
  • IdentityFile asks for the location of the identity key we made. Type in the respective path here.
  • AddKeysToAgent allows a private key that is used during authentication to be added to ssh-agent if it is running
  • UseKeychain (macOS only) allows the computer to remember the password each time it restarts
  • UserKnownHostsFile specifies an exact location to store all hosts you connect to when you’re using that profile. Provide the respective paths here and choose a unique known hosts file name (see step 2 above) so that troubleshooting and key maintenance over time is easier.
  • IdentitiesOnly specifies that only the keys provided must be used to connect to a host, even if another service like the ssh-agent offers a key for use.

Fourth: Add keys to ssh agent

Add keys to ssh agent if passphrase was used. Skip to the next step if you didn’t use a passphrase. Start the ssh agent in the terminal:

eval "$(ssh-agent -s)"

Add private keys to the agent in terminal:

ssh-add --apple-use-keychain ~/.ssh/key_name

Note that the –apple-use-keychain option works only on mac for keychain access. (In versions of MacOS prior to Monterey, use -K rather than –apple-use-keychain).

Fifth: Finishing up

If you’re using a service like Bitbucket or Github, add public keys to the clipboard and paste them into the appropriate account (i.e. Bitbucket):

cat key_name.pub | pbcopy

Finally, verify the configuration in the terminal:

ssh -T git@bitbucket.org

Repeat steps 1-5 each time you need to use a new SSH key ppair. With multiple keys, I have the option of creating new keys as needed to keep each connection secure. If I have a single compromised key, then I only worry about changing that single key. My config file makes it easy for me to use multiple keys.

References
OpenSSH documentation
Bitbucket documentation
Github documentation