Message prompts when connecting to EC2s

Improving the organization experience when SSH'in onto EC2s

Table Of Contents

Today I Explained

When you connect to instances within the organization, you’ll notice that it sometimes includes a prompt that includes the company logo & an advisory message, this looks something like the following:

              ██░░
          ▓▓░░░░  ░░▒▒
      ░░░░░░░░░░▒▒▒▒░░░░░░
██  ░░░░░░░░░░░░▒▒▒▒▒▒▒▒▒▒▒▒░░██
██▒▒░░░░░░░░░░░░▒▒▒▒▒▒▒▒▒▒▒▒▒▒
    ▒▒░░░░░░░░░░▒▒▒▒▒▒▒▒▒▒██
        ██░░░░░░▒▒▒▒▒▒▓▓
            ▒▒░░░░▒▒

:Warning! You are connected to an AEYDR Internal Machine. This machine is a production machine, and as such Data Confidentiality is in-force on this machine.

Under no circumstances are you permitted to copy data from this machine to personal workstations. Your activity while on this machine is being logged & monitored.

> Session Logged as <$AXDF>

The machine specification is defined as follows:

> EC2-i-123123123
> Scope: Production
> Tags: XYZ, XYZ, XYZ

As upfront as the message can be, you’ve likely wondered how this prompt is configured within the machines. As it knows details about the environment that it is operating within, like whether it is in production or not. This can be accomplished in a couple of ways, but commonly is done through the use of bash profiles or built-in “message of the day” functionality.

Assuming that you are always starting your sessions in these machines within bash, this will the warning message to be configured & displayed according to the .bash_profile. This will be a shell script (motd.sh) that uses the environment variables of the machine to determine which outputs to emit. In some cases, entire sections of the MOTD have been sourced from the environment for maximum customization.

This avoids the issue of having the machine images be aware of what constitutes production, and instead are just informed by environment variables that IS_PRODUCTION (or similar) is true. A minimal (non-functional) snippet is shown below for demonstrating how one of these files might look:

### Prompt Colors
if [[ $COLORTERM = gnome-* && $TERM = xterm ]] && infocmp gnome-256color >/dev/null 2>&1; then
	export TERM=gnome-256color
elif infocmp xterm-256color >/dev/null 2>&1; then
	export TERM=xterm-256color
fi

if tput setaf 1 &> /dev/null; then
	tput sgr0
	if [[ $(tput colors) -ge 256 ]] 2>/dev/null; then
		GREEN=$(tput setaf 77)
		ORANGE=$(tput setaf 172)
		MAGENTA=$(tput setaf 9)
	else
		GREEN=$(tput setaf 2)
		ORANGE=$(tput setaf 4)
		MAGENTA=$(tput setaf 5)
	fi
	BOLD=$(tput bold)
	RESET=$(tput sgr0)
else
	# ...
fi

# export ...
# ...

[ -n "$PS1" ] && {
cat << EOF
$GREEN
   #    ####### #     # ######  ######
  # #   #        #   #  #     # #     #
 #   #  #         # #   #     # #     #
#     # #####      #    #     # ######
####### #          #    #     # #   #
#     # #          #    #     # #    #
#     # #######    #    ######  #     #
$RESET
EOF
}

# ...

export PROMPT_COMMAND='echo -ne "\033]0;$${PWD##*/}\007"'

The .bash_profile can be baked into the machine images in-use within the EC2s, making use of environment variables or configuration files within AWS S3 to handle customizations.

These messages are setup typically setup by the infrastructure as code configuration. Within CloudFormation, this is type the AWS::CloudFormation::Init type that supports including metadata for EC2 instances to be executed by cfn-init. For other tools like Terraform, Chef or Ansible, these will leverage the Userdata to download & perform the software provisioning.

Alternatively, these messages are pre-baked scripts within the machine images (AMIs) used by the EC2 instances. These will already have all the users & .bash_profile configurations created during assembly, meaning that the Infrastructure as Code for the EC2s only needs to pass in the correct environment variables. This type is less common, as often machine images in-use are off-the-shelf.