The 101 Uses of OpenSSH: Part II of II
Establishing one or more user keys improves authentication security and harnesses more of SSH's power than username/password authentication. It's also the first step in using SSH in shell scripts. There's just one small obstacle to automating the things we've done with PK crypto: even though the PK crypto-based authentication is transparent, the preliminary key-authorization isn't. How can we safely skip or streamline that process?
There are several ways. One is to create a key with no passphrase, in which case none will be prompted for whenever the key is used. (We'll talk about passphrase-less keys in a moment.) Another way is to use ssh-agent.
ssh-agent is, essentially, a private-key-cache in RAM that allows you to use your private key repeatedly after entering its passphrase just once. When you start ssh-agent and then load a key into it with ssh-add, you are prompted for the key's passphrase, after which the “unlocked” private key is held in memory in such a way that all subsequent invocations ssh and scp will be able to use the cached, unlocked key without re-prompting for its passphrase.
This might sound insecure, but it isn't. First, only a ssh-agent process' owner can use the keys loaded into it. For example, if “root” and “bubba” are both logged in and each have started their own ssh-agent processes and loaded their respective private keys into them, they cannot get at each other's cached keys; there is no danger of bubba using root's credentials to run scp or ssh processes.
Second, ssh-agent listens only to local ssh and scp processes; it is not directly accessible from the network. In other words, it is a local service, not a network service per se. There is no danger, therefore, of an outside would-be intruder hijacking or otherwise compromising a remote ssh-agent process.
Using ssh-agent is fairly straightforward: simply enter ssh-agent and execute the commands it prints to the screen. This last bit may sound confusing, and it's certainly non-instinctive: before going to the background, ssh-agent prints a brief series of environment-variable declarations appropriate to whichever shell you're using that must be made before you can add any keys. Simply select these commands using your mouse and right click to paste them at a command prompt to execute them (see Listing 3).
In Listing 3, I'm one third of the way there: I've started a ssh-agent process, and ssh-agent has printed out the variables I need to declare using BASH syntax.
All I need to do now is select everything after the first line above and before the last line (as soon as I release the left mouse-button this text will be copied), and right click over the cursor on the last line (which will paste the previously selected text into that spot). I may need to hit the enter key for that last echo to be performed, but that echo isn't really necessary anyhow.
Note that the above cut and paste will work in any xterm, but for it to work at a tty (text) console gpm will need to be running. If all else fails, you can always type the declarations manually.
Once ssh-agent is running and SSH_AUTH_SOCK and SSH_AGENT_PID have been declared and exported, it's time to load your private key. Simply type ssh-add followed by a space and the name (with full path) of the private key you wish to load. If you don't specify a file, it will automatically attempt to load $HOME/.ssh/identity. Since that's the default name for an RSA user-private-key, if yours is named something else or if you wish to load a DSA key you'll need to specify its name, including its full path, e.g., ssh-add /home/mbauer/.ssh/id_dsa.
You can use ssh-add as many times (to load as many keys) as you like. This is useful if you have both an RSA and a DSA key pair and access different remote hosts running different versions of SSH (i.e., some that only support RSA keys and others that accept DSA keys).
ssh-agent is useful if you run scripts from a logon session or if you need to run ssh and/or scp repeatedly in a single session. But what about cron jobs? Obviously, cron can't perform username/password or enter a passphrase for PK authentication.
This is the place to use a passphrase-less key pair. Simply run ssh-keygen as described above, but instead of entering a passphrase when prompted hit the enter key. You'll probably also want to enter a filename other than “identity” or “id_dsa”, unless the key pair is to be the default user key for some sort of special account used for running automated tasks.
To specify a particular key to use in either an ssh or scp session, use the -i. For example, if I'm using scp in a cron job that copies logfiles, my scp line might look like this:
scp -i /etc/script_dsa_id /var/log/messages.* firstname.lastname@example.org
When the script runs, this line will run without requiring a passphrase: if the passphrase is set to <Enter>, SSH is smart enough to not bother to prompt the user.
But remember, on the remote-host-side I'll need to make sure the key in /etc/script_dsa_id.pub has been added to the appropriate authorized_keys2 file on the remote host, e.g., /home/scriptboy/.ssh/authorized_keys2.
CAUTION: always protect all private keys! When in doubt, chmod go-rwx private_key_filename.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Google's SwiftShader Released
- Interview with Patrick Volkerding
- SUSE LLC's SUSE Manager
- Tech Tip: Really Simple HTTP Server with Python
- My +1 Sword of Productivity
- Returning Values from Bash Functions
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- SuperTuxKart 0.9.2 Released
- Managing Linux Using Puppet
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide