Using Passworded Groups

An obscure, but interesting, feature of groups is that you can, in fact, assign passwords to them. The use case of this feature is that you can dynamically adopt a group into your current session, when you need a resource that requires it. When you request this, you will first be prompted for the password.

The obvious evil of doing this is that all members of the group must know the password. Still, it’s a tool to be kept at hand.

$ sudo addgroup test_pass_group
[sudo] password for dustin: 
Adding group `test_pass_group' (GID 1001) ...
Done.

$ sudo gpasswd test_pass_group
Changing the password for group test_pass_group
New Password: 
Re-enter new password: 

$ groups
dustin adm cdrom sudo dip plugdev lpadmin sambashare

$ newgrp test_pass_group
Password: 

$ groups
test_pass_group adm cdrom sudo dip plugdev lpadmin sambashare dustin

newgrp will send you into a new shell with the additional group. Therefore, to drop the group, simply exit the new shell.

Custom GIT Subcommands

At some point, you might find yourself running the same sequence of git operations on a regular basis. It would greatly improve your efficiency to stash these commands into your own Git subcommand.

For example, I could create a script named “git-dustin”:

#!/bin/sh

echo "Dustin's subcommand: $1"

Then, I’d save it into /usr/local/bin (in order to be in the path), and mark it as executable. I can then access it as if it were a subcommand:

$ git dustin "test argument"

This is the output:

Dustin, subcommand: test argument

Environment Variables Under SSH

It’s a fairly important point that if you want to define global environment variables on an Ubuntu host that will be accessible from a command executed via SSH, OpenSSH provides few options and most blogs will give users incorrect advice.

It turns out that adding variables to /etc/profile or /etc/profile.d/* is patently incorrect.

If you want to add an environment variable that any script for any user can see when executed via SSH (“ssh <user>@<host> <command>“), add it to /etc/environment. It’s similar to ~/.ssh/environment (if that’s turned-on with PermitUserEnvironment), but global.