Image of the glider from the Game of Life by John Conway
Skip to content

Use Your SSH Client To Help Prevent Stupid Mistakes

I have chosen the path of system administration for my career. It's been very rewarding, and I really love my job. However, there are times when I make stupid mistakes that cost others money. I'm sure we've all been there. It's stressful, embarrassing and can really shake you up, if you mistake is bad enough. Many times, this happens because you fat-fingered an IP address, hostname, or something else, and your SSH client takes you somewhere you shouldn't be. If that's the case, hopefully this post can help.

According to the ssh_config(5) manual:

             Specifies a command to execute on the local machine after suc‐
             cessfully connecting to the server.  The command string extends
             to the end of the line, and is executed with the user's shell.
             The following escape character substitutions will be performed:
             ‘%d’ (local user's home directory), ‘%h’ (remote host name), ‘%l’
             (local host name), ‘%n’ (host name as provided on the command
             line), ‘%p’ (remote port), ‘%r’ (remote user name) or ‘%u’ (local
             user name).

             The command is run synchronously and does not have access to the
             session of the ssh(1) that spawned it.  It should not be used for
             interactive commands.

             This directive is ignored unless PermitLocalCommand has been

As mentioned, the used of LocalCommand executes a local command after successfully connecting to the server. I figured this would be a great way to print something to the terminal, letting me know whether or not my client just connected to a production machine, a QA machine, or a development machine.

I wanted to use colors, to make it obvious. I don't want to make the same mistake twice, so I want it painfully clear what machine I just went to. As a result, if I go to a development or home machine, use green. If I enter a QA machine, use yellow. If I enter a production, or other serious machine I probably shouldn't be on, use red. As a result, I can take advantage of the ANSI escape sequences for color. In case you forgot, here are the colors and modes:


Text attributes
0 Reset
1 Bright
2 Dim
4 Underscore
5 Blink
7 Reverse
8 Hidden

Foreground Colors
30 Black
31 Red
32 Green
33 Yellow
34 Blue
35 Magenta
36 Cyan
37 White

Background Colors
40 Black
41 Red
42 Green
43 Yellow
44 Blue
45 Magenta
46 Cyan
47 White

So, if I were about to SSH to a production machine, I probably want to make it as obvious as possible. Thus, I could print to the terminal, in blinking, bold, red text "PRODUCTION". I could use the following command:

print "\e[1;5;31PRODUCTIONm\e[0;m"

Notice that at the end of the sequence, I'm resetting the text attributes. This is because if you don't do this, you will keep the text attributes in your terminal, and that may have an affect on how the text is displayed when in your remote SSH connection.

A possible ~/.ssh/config file could look like this:

Host development
    Hostname dev.domain.tld
    LocalCommand print "\e[1;32mDevelopment\e[0;m"
    PermitLocalCommand yes

Host qa
    Hostname qa.domain.tld
    LocalCommand print "\e[1;33mQuality Assurance\e[0;m"
    PermitLocalCommand yes

Host production
    Hostname prod.domain.tld
    LocalCommand print "\e[1;5;32mPRODUCTION\e[0;m"
    PermitLocalCommand yes

Here is a screenshot in action (without the blink):

{ 13 } Comments

  1. Christer Edwards | September 6, 2011 at 10:51 am | Permalink

    What about using the LocalCommand to export a variable, like maybe redefine $PS1 to use your color coding? That way it's always displayed.

  2. Aaron Toponce | September 6, 2011 at 10:53 am | Permalink

    That's actually not a bad idea. But, I'm curious if $PS1 will carry through the connection. I'm not sure that it will, but it's worth a shot.

  3. Aaron Toponce | September 6, 2011 at 10:57 am | Permalink

    Just tried it. Doesn't work. As the manual states, LocalCommand does not have access to the session that ssh(1) spawned. I think this may be as good as it gets. Of course, you could add newlines, and other things to make it blatantly obvious that you're in a production machine.

  4. Volans | September 6, 2011 at 1:44 pm | Permalink

    I'm using coloured PS1 on the remote hosts for some years now.

    I think this approach is better because has the advantage that the prompt is always visible also after many screens of commands and that can be used for any user, regardless of their SSH client configuration.

    Just configure it in one place (two to be precise, /etc/skel/.bashrc and /root/.bashrc, as well as the .bashrc of any existing user) and it's done.

  5. Aaron Toponce | September 6, 2011 at 3:46 pm | Permalink

    I'm familiar with $PS1. Sure, you can change your prompt to give you more information. However, with prompts, they quickly become backgrounded noise, and you no longer notice the information. Something like this is yet another way to grab your attention, and let you know where you are.

  6. Lonnie Olson | September 6, 2011 at 4:27 pm | Permalink

    That is a really cool idea. I've never thought of anything useful to do with LocalCommand. Thanks.

    My method to achieve that same goal of identifying the remote end very clearly is to use figlet ( to display a big banner of the hostname, and perhaps a (normal text) description of the machine. Then add that to the /etc/motd

  7. grin | September 7, 2011 at 1:51 am | Permalink

    Actually PS1+color coding is good. Color coding is generally good because your eyes get used to it and it's immediately obvious that you see a different color. PS1 in /etc/profiles or .shellrc helps everyone who uses the machine to see the point, not just me.

  8. Jeremy | September 7, 2011 at 2:55 am | Permalink

    I would like to voice my support for colour–coded PS1 as well. All my local desktops use green, whereas servers use a combination of yellow or blue depending on where they are.

    My brain is trained to know that "green is good, go ahead and apt-get install quake3", and "gold or blue, do you really want to type that quickly?".

  9. Danilo | September 7, 2011 at 5:14 am | Permalink

    I'm also using $PS1 + colors. I even use them on my local machine, green means normal user and red means root. Red immediately catches your attention, so you won't forget that you're using root permissions. Could also be used on production machines.

    The main benefit of this vs. LocalCommand is that with the latter option the warning only appears once and can't be seen anymore after issueing a few commands, while the $PS1 approach is always seen.

  10. Aaron Toponce | September 7, 2011 at 7:37 am | Permalink

    It's not about colored PS1 versus non-colored PS1. My root ZSH prompt is red, and it doesn't matter how many times I login as root, I always know I'm root, because of the red prompt.

    However, what your eyes get used to, and your mind starts blocking out, is information. Adding "production" or "root" text to your prompt starts getting ignored quickly. However, with using LocalCommand, you can create an alert that makes you immediately aware of where you are.

    So, again, it's not about PS1 versus LocalCommand. It's about making the alert visible, and in your face, so you always know where you are.

  11. Paul Tansom | September 7, 2011 at 7:44 am | Permalink

    I've used figlet to produce a large reminder of which machine I've logged into using the motd for some years, although that doesn't help much if you've left screen running! I'll have to take a closer look at this, although I do like the idea of the colour coded PS1 too. Time for a bit of playing I think 🙂

  12. Paul Tansom | September 7, 2011 at 9:17 am | Permalink

    OK, after some experimentation I found I needed to use:

    echo -e '33[31mPRODUCTION33[39m'

    instead of the print command on my Ubuntu installs (Bash), but it seems there is little point using it anyway as it all happens in a flash before switching to screen/byobu so you barely see it!

    Oh well, time to take a look at the PS1 option now I've started playing 🙂

  13. foo | September 11, 2011 at 4:10 pm | Permalink

    Probably you want this too:

Post a Comment

Your email is never published nor shared.