SSH to production? Do you do it to figure out why a particular bug is happening? Do you mimic same actions locally to narrow that nasty bug down? If so, did you ever do something on the production server that you planned to do on the local one?
I’m guessing the answer is yes and not just once otherwise you wouldn’t be reading this. If you’ve been a web developer even for a small amount of time this is a part of life. You’ve been debugging for a while so you lose focus. At one moment you see that you screwed up and you sweat up like crazy After realizing what you’ve done you can only hope that you didn’t do too much damage and that it can all be reverted.
But it doesn’t have to be like that. So the last time this happened to me I started looking if there’s anything that would visually distinguish which of my tabs is connected to production. I started looking around and found a way to change that tab color. But I also found a way to change the profile automatically. About an hour of copy/pasting and experimenting later and this is what I ended up with:
Notice that the tab and profile color change the moment I
ssh to the server. And it automagically goes away as soon as I exit it. Isn’t this awesome?
OK, so what do we have here? Basically we alias
colorssh. And that one checks if the server we’re connecting to is one of the production ones (in this sample script they are
ec2-.*compute-1). If that is the case then it changes iTerm2 profile to
SSH and tab color to red.
If you have the same setup as me then just place the above script in
~/.oh-my-zsh/custom, and create profile with the name
SSH in iTerm2. You can find lots of great color schemes here.
On a different setup you’ll have to do some investigating work on your own. But it can all be done even with plain bash and regular Terminal. I derived my script from:
- Change terminal color when SSH from OS-X
- Mac OS X Terminal: visual indication for your ssh connection
- Change iTerm2 tab color when using SSH
- Changing terminal color in MacOSX when SSHing