The 101 Uses of OpenSSH: Part II of II
Most people who use SSH never get past its simplest two functions: encrypted remote shells and encrypted file transfers (which is as far as we got last month in this column). That's fine; there's no point in learning features you don't need. But many of you highly self-motivated readers doubtlessly stand to benefit from at least some of SSH's other 99 uses. So let's get down to the really cool features of SSH, specifically those of OpenSSH.
Note: throughout this article I'll use “SSH” to refer to Secure Shell generically, i.e., “the Secure Shell system”. Specific Secure Shell processes will be displayed in fixed-width font and in lowercase, e.g., ssh, sshd, etc. This is consistent with my other articles: if it looks like something you'd see typed at a console-prompt, it probably is.
A complete description of public-key cryptography (or “PK crypto”) simply won't fit in an article that's supposed to be about OpenSSH. If you're completely unfamiliar with PK crypto, I highly recommend the RSA Crypto FAQ (available at http://www.rsasecurity/rsalabs/faq/) or, even better, Bruce Schneier's excellent book Applied Cryptography.
For our purposes here, it's enough to say that in a public-key scheme each user has a pair of keys. Your private key is used to digitally sign things, and to decrypt things that have been sent to you. Your public key is used by your correspondents to verify things that have allegedly been signed by you and to encrypt data that they want only you to be able to decrypt.
Along the bottom of Figure 1 we see how two users' key pairs are used to sign, encrypt, decrypt and verify a message sent from one user to the other. Note that Bob and Alice possess copies of each other's public keys but that each keeps their private key secret.
As we can see, the message's journey includes four different key actions: (1) Bob signs a message using his private key; (2) Bob encrypts it using Alice's public key (NOTE: aside from the fact that Bob has probably kept a copy of the original message, he can not decrypt this message—only Alice can); (3) Alice receives the message and decrypts it with her private key; and (4) Alice uses Bob's public key to verify that it was signed using his private key.
Compared to block ciphers such as blowfish and IDEA, in which the same key is used both for encryption and decryption, this may seem convoluted. Unlike block ciphers, for which secure key-exchanges ensure that both parties obtain the key without exposing the key to eavesdropping or other attacks, PK crypto is easier to use securely.
This is because in PK schemes two parties can send encrypted messages to each other, without first exchanging any secret data whatsoever. There is one caveat: public-key algorithms are slower and more CPU-intensive than other classes of cryptographic algorithms such as block ciphers and stream ciphers (e.g., 3DES and RC4, respectively). As it happens however, PK crypto can be used to securely generate keys that can be used in other algorithms.
In practice, therefore, PK crypto is often used for authentication (“are you really you?”) and key-negotiation (“which 3DES keys will we encrypt the rest of this session with?”) but seldom for the bulk encryption of entire sessions (data streams) or files. This is the case with SSL, and it's also the case with SSH.
Key-negotiation is one of the very first things that happens in any SSH transaction, and the thing that enables a relatively weak form of authentication (username/password combinations) to be used. How the Diffie-Hellman Key Exchange Protocol works is both beyond the scope of this article and complicated (for more information, see the Internet Draft entitled “draft-ietf-secsh-transport-07.txt”, available at http://www.ietf.org/). You need only to know that the result of this large-prime-number hoedown is a session key that both parties know but which has not actually traversed the as-yet-unencrypted connection.
This session key is used to encrypt the data fields of all subsequent packets via a “block cipher” agreed upon by both hosts (transparently but based on how each SSH process was compiled and configured). Usually one of the following is used: Triple-DES (3DES), blowfish, or IDEA. Only after session-encryption begins can authentication take place.
But before we dive into RSA/DSA authentication, let's pause for a moment and consider how key-negotiation can be transparent, given that it uses PK crypto and that private keys are usually passphrase-protected. SSH uses two different kinds of key pairs: host keys and user keys.
A host key is a special key pair that doesn't have a passphrase associated with it. Because it can be used without anybody needing to enter a passphrase first, SSH can negotiate keys and set up encrypted sessions completely transparent to users. Part of the SSH installation process is the generation of a host key (pair). The host key generated at setup time can be used by that host indefinitely, barring root compromise. And Because the host key identifies the host, not individual users, each host needs only one host key. Note that host keys are used by all computers that run SSH regardless of whether they run only the SSH client (ssh), SSH dæmon (sshd), or both.
A user key is a key associated with an individual user and is used to authenticate that user to the hosts he or she initiates connections to. Most user keys must be unlocked with the correct passphrase before being used.
User keys provide a more secure authentication mechanism than username/password authentication (even though all authentication occurs over encrypted sessions). For this reason, SSH by default always attempts PK authentication before falling back to username/password.
When you invoke SSH, SSH checks your $HOME/.ssh directory to see if you have a private key (named “id_dsa”). If you do, SSH will prompt you for the key's passphrase and will then use the private key to create a signature that will send, along with a copy of your public key, to the remote server.
The server will check to see if the public key is an allowed key (i.e., belonging to a legitimate user and therefore present in the applicable $HOME/.ssh/authorized_keys2 file). If the key is allowed and identical to the server's previously stored copy of it, the server will use it to verify that the signature was created using this key's corresponding private key. If this succeeds, the server will allow the session to proceed, possibly after also performing username/password authentication.
(Note: the above two paragraphs refer to the DSA authentication used in SSH Protocol v.2; RSA authentication is slightly more complicated but, other than using different filenames, is functionally identical from the user's perspective.)
PK authentication is more secure than username/password because a digital signature cannot be reverse-engineered or otherwise manipulated to derive the private key which generated it; neither can a public key. By sending only digital signatures and public keys over the network, we ensure that even if the session key is somehow cracked, an eavesdropper still won't be able to obtain enough information to log on illicitly.
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!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Tech Tip: Really Simple HTTP Server with Python
- Doing for User Space What We Did for Kernel Space
- Parsing an RSS News Feed with a Bash Script
- Rogue Wave Software's Zend Server
- SuperTuxKart 0.9.2 Released
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