In the world of a Unix / Linux administrator, OpenSSH is nearly ubiquitous. I often to refer to it as the sysadmin’s network “swiss-army” knife because it enables simple automation, file transfers and administration of every day tasks. Doing it securely all the while!
However, though most of us use SSH daily (probably hundreds of times per day for TLF guys) the SSH client configuration options are curiously underused in most situations. Normally kept in ~/.ssh/config along with your private and public keys, the myriad of configurable tweaks that can be made to SSH can help improve your efficiency in your day-to-day work.
To get you started, I present a few examples of options and settings I use on my own account. Of course we encourage you to read the man page for ssh_config (usually ‘man 5 ssh_config’ on most Linuxes) and delve into your own customizations too!
What It Does: Tells the SSH client when to consider the connection “dead” after not receiving any data from the server. When a “dead” connection is determined, the client will disconnect from the server The value is in seconds.
Why I Use It: Though there is also a separate configuration for TCPKeepAlive, I’ve found using this SSH-level server message keepalive in conjunction helps keep connections healthy when things blink. Example: I can usually upgrade SSHD and restart the daemon remotely, and still remain connected. Near magic!
What It Does: Sets the behavior of SSH when connecting to a host with new or changed host keys.
Why I Use It: Though the setting sounds insecure, it isn’t. There is no way to tell SSH to completely disable host keys since that would inherently make it insecure. Rather, a ‘no’ value here tells SSH to automatically add new host keys to ~/.ssh/known_hosts, skipping the yes or no prompt which you’re forced to answer. Existing keys in known_hosts that have changed will continue to prompt, which is the primary reason of maintaining that file in the first place. Minor time and annoyance saver.
What It Does: Modifies the behavior of connection re-use by the SSH server and client.
Why I Use It: By default, SSH will re-use a single control connection for multiple SSH sessions to the same server. Bet you didn’t know that! Try opening multiple terminals and connect to the same server with them. You should only see one socket used if a ‘netstat -an’ is run. While that’s a great idea and saves resources, in some cases (for sysadmin purposes), I want it to run in several separate network connections. This is purely a way for me to eliminate SSH as a problem in some troubleshooting situations.
What It Does: Controls how many password attempts are allowed before SSH dumps you back to a shell prompt in failure. Defaults to 3.
Why I Use It: Some days are better typing days than others. I’ll be the first to admit that my worse typing days outnumber my good ones. For years I thought the SSHD daemon controlled the password attempt count, so imagine my chagrin when I found out I could simply set a value and have it ask me a few more times instead!
There you have it! A few selections from my own ~/.ssh/config file. It doesn’t end here! There are methods to customize settings for a certain host or subset of hosts, set custom user names for specific servers so you don’t have to remember them, customize which local environment variables get replicated to the destination server and more.
Over the years, OpenSSH has proven itself to be an invaluable tool. Make the most of it!