Use caution when making changes to bash configurations in Linux

When you’ve been doing something for decades, certain things become so ingrained into your habit that you take them for granted. Such is the case with Linux. I’ve been using it since the late ’90s, so habits have been deeply ingrained. I know to do certain things, and I do them without thinking. 

SEE: 5 Linux server distributions you should be using (TechRepublic Premium)

Such is the case when working with systems like SSH or bash.

But not everyone knows about these habits, these fundamental things we do without thinking. And there’s a parallel to be drawn, one that I’ll share with you now.

I have to read through a lot of documentation. A. Lot. Of. Documentation. Very often I find that most documentation is either poorly written, broken or takes numerous shortcuts such as:

Do X (read how to do X here).

I get that. I’ve done it. But when someone is in a flow, trying to get something up and running quickly, they don’t want to have to keep clicking links to open even more documentation to make whatever it is they are trying to deploy work. At a bare minimum, you (and your users) would be better served with something like:

1. Do X – here’s the breakdown of those steps:
2. Do A.
3. Do B.
4. Do C.

When we take shortcuts, problems can occur. This is especially so when you start monkeying around with SSH and bash. Configure either one of those improperly and you could wind up locking yourself out of SSH connections or incapable of logging into your account. Both of those situations can throw a serious wrench into the works of your day. 

SEE: Rust: What developers need to know about this programming language (free PDF) (TechRepublic)

So you rely on good habits to keep them from happening.

Problem is, if you’ve not been using Linux for long, those good habits have yet to settle in. With that in mind, I’m going to give you a piece of advice that you’ll need to remember every time you go to work with SSH or bash. Consider this advice as fundamental as it gets for Linux admins.

Are you ready for that advice, because here it comes?

When you’re configuring either SSH or bash it is crucial that you test those changes before you close the terminal you’re working in. Let me explain.

1. You’ve logged into a remote machine and are configuring its SSH daemon.
2. After you’ve made the changes and restarted the SSH service, stay logged in with the current terminal.
3. Attempt to remote into that server, via SSH, using a different terminal.
4. If the SSH connection works, you should be OK to close out the original window.
5. If the SSH connection fails, get back to work and reconfigure via the original terminal window.
6. Wash, rinse, repeat until the connection works.

The same thing holds true when working with bash:

1. Log into the machine in question.
2. Make your changes to .bashrc (or whatever bash file you’re working with).
3. Save the changes.
4. Open another terminal on the same machine.
5. If the new terminal works as expected (and whatever configuration changes you made are satisfactory), close both terminals and move on to the next task.
6. If the terminal doesn’t work, go back to the original terminal and troubleshoot the problem.
7. Wash, rinse, repeat until you can open a second terminal without issue.

The key here is to remember you could seriously FUBAR your day by an improperly configured bash or SSH. Imagine you’ve tanked the .bashrc configuration file to the point where it will no longer allow you to log in with that user. Trust me, I’ve done this a time or two in my early days. It’s not fun…especially when you know you could have avoided the disaster by erring on the side of caution.

And that’s the key here … caution. You’re working on your data center (not a desktop), so you must always err on that particular side of the fence. And until you have those particular types of habits ingrained into your muscle memory, never fail to remind yourself that a bit of extra testing will go a long way to prevent your day from being ruined by a simple mistake. This is especially true when making changes to systems like bash and SSH on a production machine, where one misplaced character could make the difference between you being able to log in or not.

In the end, always test before you close out that terminal.

And for those who write documentation for the programs and services you create, don’t skip steps, and always keep those documents up to date.

Open Source Weekly Newsletter

You don’t want to miss our tips, tutorials, and commentary on the Linux OS and open source applications.
Delivered Tuesdays

Sign up today

Also see