The ssh_config(5) manpage lists many other configuration options. For example, there is one machine that I occasionally access that requires a very specific combination of options on the command line. (It's a home-grown version of the SSH server that not only doesn't implement all the features but gets confused if you try to negotiate anything it doesn't understand.) The command I have to type to get it just right is: $ ssh -x -o RSAAuthentication=yes -o PasswordAuthentication=yes -o ChallengeResponseAuthentication=no -1 peter.example.net
I could have set up a shell alias, but instead I can modify the SSH configuration, and all systems that use SSH will do the right thing. If a script that I can't modify uses SSH to reach that machine, these settings will still be used.
The lines in my ~/.ssh/config file look like this: Host peter.example.net ForwardX11 no RSAAuthentication yes PasswordAuthentication yes ChallengeResponseAuthentication no Compression no Protocol 1
SSH clients for Windows tend to have a GUI that will let you save profile settings to be used for a particular host or hosts.
The more you learn about SSH, the more you can do with it. There are many good books and online tutorials on the finer points of SSH, such as SSH, The Secure Shelclass="underline" The Definitive Guide (O'Reilly). If there is one thing every system administrator should, but may not, know about SSH, it is how to set up public/private keys to securely eliminate the need to type passwords when SSHing from one specific machine to another.
A Makefile for Every Host
This section applies to Unix/Linux systems. Windows folks might want to skip it.
Unix/Linux systems often maintain critical information in plain text files that are edited by hand. Sometimes, after editing a file, you have to run a command to inform the system that the information has changed.
SSH to the Right Server in a Web Farm Every Time
Suppose you have three servers: server1.example.com , server2.example.com , and server3.example.com . You have many web sites divided among them, and remembering which site is on which server is getting to be a drag. Is www.everythingsysadmin.com on server 1 or 3? You think it's on 3, but someone may have moved it to 2 when you ran low on disk space. Why try to remember at all? No need to set up a configuration file, just SSH to the web site's hostname! For example, type ssh www.everythingsysadmin.com and soon you'll find yourself on the right machine. OK, that's pretty obvious, but you'd be surprised how often people forget that it works!
For example, after editing /etc/aliases (part of sendmail, Postfix, and various mail-transport-agent packages), you must run the newaliases command. That's pretty easy to remember, right?
After editing Postfix's transports file, should you run the newtransports command? No, that would be too obvious. You must run postmap transports. And there is the m4 command to run after editing .m4 files, and so on and so on.
Who has time to remember which command is used after which file is edited? Details like that are what computers are for.
make to the rescue! You might think of make as a programming tool—the program you run when compiling software. In reality, it lets you set up any kind of relationship involving the need to run a command to update one file if another changes.
Tip
make is one of the most powerful system administration tools ever invented. I hear programmers find it useful, too!
make has more features than Liz Taylor has had husbands, so I'll give a short introduction. (If you read the first two chapters of most books on make, you'll know 99 percent of what you need to for most system administration tasks and 10 times more than what your coworkers know.)
A Brief Introduction to make
make reads a configuration file aptly named Makefile. In this file, you will find recipes. They instruct make how to do its work.
Each recipe looks like this: whole: partA partB partC command that creates whole
The recipe begins with the file that is going to be created, then a colon, and then it lists the files needed to build the main file. In this example, the recipe is about whole and establishes a relationship between it and partA, partB, and partC. If partA, partB, or partC is ever updated, then we need to (re)run the command that generates whole.
A real-world example helps: aliases.db: aliases newaliases @echo Done updating aliases
This code means that if aliases is changed, regenerate aliases.db using the command newaliases. Then the recipe outputs "Done updating aliases" to announce its success.
Notice that the second and third lines of the recipe are indented. They must be indented with a tab, not multiple spaces. Why? My theory is that the original creator of make wanted to punish me every time I use cut-and-paste on a system that turns tabs into spaces. However, I don't take it personally.
The update doesn't happen automatically. You have to run make to make it happen: Server1# make aliases.db newaliases Done updating aliases Server1#
That's it! make read its configuration file, figured out that aliases was newer than aliases.db by checking the timestamp of the files, and determined that running newaliases would bring aliases.db up-to-date. If we run it again: Server1# make aliases.db Server1#
There's no output. Why? Because now the timestamps on the files indicate that there is no work to be done: aliases.db is newer than aliases. make is lazy and will calculate the minimum amount of work required to do what you ask. It makes these decisions based on the timestamps of the files.
Here's another Makefile code sample: file1.output: file1.input command1 <file.input >file.output file2.output: file2.input command2 file2.input >$@
In the first example, the command to be run uses stdin and stdout (file redirection using < and >) to read file.input and write file.output. The second example is similar, but the command takes the input filename on the command line and redirects the output to...what? Oh, $@ means "The file that this recipe is creating," or, in this case, file2.output. Why isn't it something simple like $me or $this? Who knows! You don't have to use $@, it just makes you look smarter than your coworkers.
make with no command-line parameters runs the first recipe in Makefile. It is traditional to name the first recipe all and have it run all the recipes you would expect as the default. This way, running make makes all the important recipes. It might not be literally all the recipes, but it is all the recipes you want to make by default. It might look like this: alclass="underline" aliases.db access.db