Individual Entry

ssh-ecurity — Part 3: Its keys to success.

In the prior "ssh-ecurity" blogs, I've introduced the ssh concept and command. In short, ssh provides a way of communicating between two systems in a secure fashion using encryption. Undoubtedly, you've heard the term encryption before; it's nothing new. Famous examples exist from ancient times to more modern times. An entire science of cryptography was born out of trying to decipher encoded communications intercepted during the course of World War II. Google "German Enigma" or "Japanese Purple" for some background and the history of cryptography. In general terms, encryption is a process whereby the information to be transmitted or stored/archived is converted into a secret format that connot be readily understood by someone who is not authorized to have access to that information.

When I was young, my family (all of German descent) would speak in German or Pennsylvania Dutch when there was some discussion that the children should not be privy to. Of course, it helped a great deal that the children did not know the language. That was their encryption method when there was some need for secrecy.

The key to encryption is two-fold. One, knowing the methodology to encrypt the information and two, knowing the paraphrase supplied to the encryption engine. During World War II, both the German Enigma and the Japanese Purple cyphers were broken by the fact that, by human nature, the operators of the encypting systems chose pass-phrases with certain predictability which lead to a statistical method for discerning the methodology and thus, the decryption of the intercepted communications. Many historians claim this was key to winning the war.

There are two classes of encryption technology. I'll call them: one-way and two-way.

There are some encryption schemes which are one-way. This may seem odd. One-way encryption sounds about as useful as write-only memory. What good is encrypting data that cannot be decrypted? Well, as strange as it sounds, it's used quite commonly. In fact, the system you logged into to access the internet and then this blog likely used a one-way encryption to store your password. The password, once encrypted using the one-way scheme, cannot be recovered. So, how does it then authenticate your password? Simple, when you supply your password upon logging in, the same algorithm used to encrypt the stored password is applied to the password you entered. The resultant one-way encrypted password is then compared to that which is stored. If they compare, you are authenticated. Very similar schemes are used for web site login authentication. For further info, google MD5-digest.

The type of encryption used in ssh is two-way. Most, but not all, such encryption technologies use a system of
"keys" that allow allow the information to be encoded and, later, decoded. When discussing ssh, there are several type of keys you may hear mentioned: private key, public key, and host key. So, before delving into uses of these key types in later blogs, I think it is a good time to take a brief look at each of these terms and define them.

Private Key

Private key refers to one of two keys used in what is known as public-key encryption. The other key is referred to as the public key. The private key is used it to encrypt outgoing information and decrypt incoming information. This key acts as the users secret pass-phrase and it should remain protected and secret. This will be further clarified in a moment.

Public Key

Public key refers to one of two keys used in what is known as public-key encryption. The other key is referred to as the private key. The public key allows users who possess it to read information encrypted by the private key and to encrypt information that can only be decrypted with the private key. This key is distributed to users and systems with whom you want to share your encrypted information. It is the second half of public-key encryption next discussed.

Public Key Encryption

Public key encryption of an encoding scheme which employs an asymmetric algorithm to encrypt and decrypt information. A pair of disparate but related keys (public and private) are employed to facilitate this scheme. The public key is used to encrypt the information which can only be decrypted by the corresponding private key.

Public Key Authentication

The public and private key pair is used to identify the user to an SSH2 server much like the username and password are used in tradition login verification. The user creates both a public and private key. The public key is then transferred to the host which the user wants to securely access. The private key, which is maintained on the user's local machine, is used to verify his or her identity when connecting to the remote host with the corresponding public key. The public and private keys must correspond to permit the secure connection.

Host Key Authentication

Host key authentication employs a host key which is a public key and is used is manner similar to public key authentication. The host keys for a system are usually created when the ssh server is configured. It is a unique key pair for the system. The public key is transferred to the remote client user when the client connects to the server. When then client first connects to the server using ssh, the server sends its public host key to the client. The server maintains the private key, hopefully, securely to itself. Typically, during the first connection attempt to the remote host, the user is prompted asking to save the host key. If the user responds affirmatively to the query, the remot host's public key is stored in the local user's profile (host key database). Subsequent connections to the remote hosts will seek this public key in order to authenticate the connection.

If the keys are determined to be valid, the connection is instantiated. If the remote host sends a different host key, the client will be alerted to the fact. There are several ways that this can occur.

  1. The user's stored public key for the remote host has been corrupted.
    Never edit host keys stored on a system. Doing so is a sure-fire way to lock users out; especially, on OpenVMS systems which maintain file attributes that might change even if the file's contents did not.

  2. The remote host server's key pair has changed.
    A server's host keys are usually created when ssh is configured. If there is a need to reconfigure ssh, do not recreate the host keys created when ssh was initially configured. Doing so will lock out users that have previously authenticated using the old pair.
  3. There is an imposter in the connection scenario;
    Either the client user or, more commonly, the remote host server. The ssh client will alert the user to this and then prompt them as to whether or not to proceed and accept a new host key.

Encryption Algorithms

There are two encryption algorithms you will encounter when dealing with ssh.
  1. RSA
    The RSA algorithm was first described by Ron Rivest, Adi Shamir, and Leonard Adleman at MIT. The algorithm is known by the letters RSA; the initials of their surnames. The mathematical details of the algorithm are too complex for any discussion here. The knowledge that such an algorithm exists is the only reason for mentioning it here.

  2. DSA
    DSA stands for Digital Signature Algorithm and was developed by the US Government (NIST). Like RSA, the mathematics are far too complex for any exploration here. Again, the only reason I mention it is so that you are aware of its existence.
These two algorithms are available in ssh.

This is an over-simplified and lay introduction to the keys to ssh but, I believe, it is important to have some understanding of them before proceeding with further discussion of ssh features.


Comments?


To thwart automated comment SPAM, you must answer this question to post.

Comment moderation is enabled. Your comment(s) will not be visisble until approved.
Remember personal info?
Notify?
Hide email?
All html tags, with the exception of <b> and <i>, will be removed from your comment. You can make links by simply typing the url or email-address.
Powered by…