Data that can be read and understood without any special measures is called plaintext or cleartext. The method of disguising plaintext in such a way as to hide its substance is called encryption. Encrypting plaintext results in unreadable gibberish called ciphertext. You use encryption to ensure that information is hidden from anyone for whom it is not intended, even those who can see the encrypted data. The process of reverting ciphertext to its original plaintext is called decryption.
Data Encryption Methods
Cryptography involves all legitimate users of information having the keys required to access that information.
- If the sender and recipient must have the same key in order to encode or decode the protected information, then the cipher is a symmetric key cipher since everyone uses the same key for the same message. The main problem is that the secret key must somehow be given to both the sender and recipient privately. For this reason, symmetric key ciphers are also called private key (or secret key) ciphers.
- If the sender and recipient have different keys respective to the communication roles they play, then the cipher is an asymmetric key cipher as different keys exist for encoding and decoding the same message. It is also called public key encryption as the user publicly distributes one of the keys without a care for secrecy. In the case of confidential messages to the user, they distribute the encryption key. Asymmetric encryption relies on the fact that possession of the encryption key will not reveal the decryption key.
- Digital Signatures are a form of authentication with some parallels to public-key encryption. The two keys are the public verification key and the secret signature key. As in public-key encryption, the verification key can be distributed to other people, with the same caveat that the distribution process should in some way authenticate the owner of the secret key. Security relies on the fact that possession of the verification key will not reveal the signature key.
- Hash Functions are unkeyed message digests with special properties.
The two primary types of encryption are symmetric and asymmetric key encryption.
Symmetric Key Encryption – It means both sender and receiver use the same secret key to encrypt and decrypt the data. A secret key, which can be a number, a word, or just a string of random letters, is applied to the text of a message to change the content in a particular way. This might be as simple as shifting each letter by a number of places in the alphabet.
As long as both sender and recipient know the secret key, they can encrypt and decrypt all messages that use this key. The drawback to symmetric key encryption is there is no secure way to share the key between multiple systems. Systems that use symmetric key encryption need to use an offline method to transfer the keys from one system to another. This is not practical in a large environment such as the Internet, where the clients and servers are not located in the same physical place. The strength of symmetric key encryption is fast, bulk encryption. Weaknesses of symmetric key encryption are key distribution, scalability, limited security (confidentiality only) and The fact that it does not provide non-repudiation, meaning the sender’s identity can be proven.
Examples of symmetric algorithms are DES (data encryption standard), 3DES, AES (Advanced Encryption Standard), IDEA (International Data Encryption Algorithm), Twofish, RC4 (Rivest Cipher 4)
Asymmetric (or public) key cryptography – It was created to address the weaknesses of symmetric key management and distribution. But there’s a problem with secret keys: how can they be exchanged securely over an inherently insecure network such as the Internet?
Anyone who knows the secret key can decrypt the message, so it is important to keep the secret key secure. Asymmetric encryption uses two related keys known as a key pair. A public key is made available to anyone who might want to send you an encrypted message. A second, private key is kept secret, so that only you know it. Any messages (text, binary files, or documents) that are encrypted by using the public key can only be decrypted by using the matching private key. Any message that is encrypted by using the private key can only be decrypted by using the matching public key. This means that you do not have to worry about passing public keys over the Internet as they are by nature available to anyone. A problem with asymmetric encryption, however, is that it is slower than symmetric encryption. It requires far more processing power to both encrypt and decrypt the content of the message.
Public Key Infrastructure
Public-key cryptography (also called asymmetric-key cryptography) uses a key pair to encrypt and decrypt content. The key pair consists of one public and one private key that are mathematically related. An individual who intends to communicate securely with others can distribute the public key but must keep the private key secret. Content encrypted by using one of the keys can be decrypted by using the other. Assume, for example, that Bob wants to send a secure email message to Alice. This can be accomplished in the following manner
- Both Bob and Alice have their own key pairs. They have kept their private keys securely to themselves and have sent their public keys directly to each other.
- Bob uses Alice’s public key to encrypt the message and sends it to her.
- Alice uses her private key to decrypt the message.
This simplified example highlights at least one obvious concern Bob must have about the public key he used to encrypt the message. That is, he cannot know with certainty that the key he used for encryption actually belonged to Alice. It is possible that another party monitoring the communication channel between Bob and Alice substituted a different key.
The public key infrastructure concept has evolved to help address this problem and others. A public key infrastructure (PKI) consists of software and hardware elements that a trusted third party can use to establish the integrity and ownership of a public key. The trusted party, called a certification authority (CA), typically accomplishes this by issuing signed (encrypted) binary certificates that affirm the identity of the certificate subject and bind that identity to the public key contained in the certificate. The CA signs the certificate by using its private key. It issues the corresponding public key to all interested parties in a self-signed CA certificate. When a CA is used, the preceding example can be modified in the following manner
- Assume that the CA has issued a signed digital certificate that contains its public key. The CA self-signs this certificate by using the private key that corresponds to the public key in the certificate.
- Alice and Bob agree to use the CA to verify their identities.
- Alice requests a public key certificate from the CA.
- The CA verifies her identity, computes a hash of the content that will make up her certificate, signs the hash by using the private key that corresponds to the public key in the published CA certificate, creates a new certificate by concatenating the certificate content and the signed hash, and makes the new certificate publicly available.
- Bob retrieves the certificate, decrypts the signed hash by using the public key of the CA, computes a new hash of the certificate content, and compares the two hashes. If the hashes match, the signature is verified and Bob can assume that the public key in the certificate does indeed belong to Alice.
- Bob uses Alice’s verified public key to encrypt a message to her.
- Alice uses her private key to decrypt the message from Bob.
In summary, the certificate signing process enables Bob to verify that the public key was not tampered with or corrupted during transit. Before issuing a certificate, the CA hashes the contents, signs (encrypts) the hash by using its own private key, and includes the encrypted hash in the issued certificate. Bob verifies the certificate contents by decrypting the hash with the CA public key, performing a separate hash of the certificate contents, and comparing the two hashes. If they match, Bob can be reasonably certain that the certificate and the public key it contains have not been altered. A typical PKI consists of the following elements.
| Element | Description |
| Certification Authority | Acts as the root of trust in a public key infrastructure and provides services that authenticate the identity of individuals, computers, and other entities in a network. |
| Registration Authority | Is certified by a root CA to issue certificates for specific uses permitted by the root. In a Microsoft PKI, a registration authority (RA) is usually called a subordinate CA. |
| Certificate Database | Saves certificate requests and issued and revoked certificates and certificate requests on the CA or RA. |
| Certificate Store | Saves issued certificates and pending or rejected certificate requests on the local computer. |
| Key Archival Server | Saves encrypted private keys in the certificate database for recovery after loss. |
PKI is an arrangement that binds public keys with respective user identities by means of a certificate authority (CA). The user identity must be unique within each CA domain. The third-party validation authority (VA) can provide this information on behalf of CA. The binding is established through the registration and issuance process, which, depending on the assurance level of the binding, may be carried out by software at a CA or under human supervision. The PKI role that assures this binding is called the registration authority (RA), which ensures that the public key is bound to the individual to which it is assigned in a way that ensures non-repudiation.
SSH
Secure Shell (SSH), sometimes known as Secure Socket Shell, is a UNIX-based command interface and protocol for securely getting access to a remote computer. It is widely used by network administrators to control Web and other kinds of servers remotely.
SSH uses public-key cryptography to authenticate the remote computer and allow it to authenticate the user, if necessary. There are several ways to use SSH; one is to use automatically generated public-private key pairs to simply encrypt a network connection, and then use password authentication to log on.
Another is to use a manually generated public-private key pair to perform the authentication, allowing users or programs to log in without having to specify a password. In this scenario, anyone can produce a matching pair of different keys (public and private). The public key is placed on all computers that must allow access to the owner of the matching private key (the owner keeps the private key secret). While authentication is based on the private key, the key itself is never transferred through the network during authentication. SSH only verifies whether the same person offering the public key also owns the matching private key. In all versions of SSH it is important to verify unknown public keys, i.e. associate the public keys with identities, before accepting them as valid. Accepting an attacker’s public key without validation will authorize an unauthorized attacker as a valid user.
SSH is typically used to log into a remote machine and execute commands, but it also supports tunneling, forwarding TCP ports and X11 connections; it can transfer files using the associated SSH file transfer (SFTP) or secure copy (SCP) protocols. SSH uses the client-server model. The standard TCP port 22 has been assigned for contacting SSH servers.
An SSH client program is typically used for establishing connections to an SSH daemon accepting remote connections. SSH is important in cloud computing to solve connectivity problems, avoiding the security issues of exposing a cloud-based virtual machine directly on the Internet. An SSH tunnel can provide a secure path over the Internet, through a firewall to a virtual machine.
Some of the applications below may require features that are only available or compatible with specific SSH clients or servers. For example, using the SSH protocol to implement a VPN is possible, but presently only with the OpenSSH server and client implementation.
- For login to a shell on a remote host (replacing Telnet and rlogin)
- For executing a single command on a remote host (replacing rsh)
- For setting up automatic (passwordless) login to a remote server (for example, using OpenSSH)
- Secure file transfer
- In combination with rsync to back up, copy and mirror files efficiently and securely
- For forwarding or tunneling a port (not to be confused with a VPN, which routes packets between different networks, or bridges two broadcast domains into one).
- For using as a full-fledged encrypted VPN. Note that only OpenSSH server and client supports this feature.
- For forwarding X from a remote host (possible through multiple intermediate hosts)
- For browsing the web through an encrypted proxy connection with SSH clients that support the SOCKS protocol.
- For securely mounting a directory on a remote server as a filesystem on a local computer using SSHFS.
- For automated remote monitoring and management of servers through one or more of the mechanisms discussed above.
- For development on a mobile or embedded device that supports SSH.
OpenSSH
OpenSSH is the premier connectivity tool for remote login with the SSH protocol. It encrypts all traffic to eliminate eavesdropping, connection hijacking, and other attacks. In addition, OpenSSH provides a large suite of secure tunneling capabilities, several authentication methods, and sophisticated configuration options. The OpenSSH suite consists of the following tools:
- Remote operations are done using ssh, scp, and sftp.
- Key management with ssh-add, ssh-keysign, ssh-keyscan, and ssh-keygen.
- The service side consists of sshd, sftp-server, and ssh-agent.
There are two different sets of configuration files: those for client programs (that is, ssh, scp, and sftp), and those for the server (the sshd daemon). System-wide SSH configuration information is stored in the /etc/ssh/ directory.
| Configuration | File Description |
| /etc/ssh/moduli | Contains Diffie-Hellman groups used for the Diffie-Hellman key exchange which is critical for constructing a secure transport layer. When keys are exchanged at the beginning of an SSH session, a shared, secret value is created which cannot be determined by either party alone. This value is then used to provide host authentication. |
| /etc/ssh/ssh_config | The default SSH client configuration file. Note that it is overridden by ~/.ssh/config if it exists. |
| /etc/ssh/sshd_config | The configuration file for the sshd daemon. |
| /etc/ssh/ssh_host_dsa_key | The DSA private key used by the sshd daemon. |
| /etc/ssh/ssh_host_dsa_key.pub | The DSA public key used by the sshd daemon. |
| /etc/ssh/ssh_host_key | The RSA private key used by the sshd daemon for version 1 of the SSH protocol. |
| /etc/ssh/ssh_host_key.pub | The RSA public key used by the sshd daemon for version 1 of the SSH protocol. |
| /etc/ssh/ssh_host_rsa_key | The RSA private key used by the sshd daemon for version 2 of the SSH protocol. |
| /etc/ssh/ssh_host_rsa_key.pub | The RSA public key used by the sshd for version 2 of the SSH protocol. |
The configuration options found in the sshd_config file.
- AuthorizedKeysFile Specifies the file that contains the public keys that can be used for user authentication. The default is /<User_Home_Directory>/.ssh/authorized_keys .
- Ciphers This is a comma-separated list of ciphers allowed for protocol version 2. Examples of supported ciphers are 3des-cbc, aes256-cbc, aes256-ctr, arcfour, and blowfish-cbc.
- HostKey Defines the file containing a private host key used by SSH. The default is /etc/ssh/ssh_host_rsa_key or /etc/ssh/ssh_host_dsa_key for protocol version 2.
- Port Specifies the port number that sshd listens on. The default value is 22.
- Protocol This specifies the protocol versions sshd supports. The possible values are 1 and 2. Note that protocol version 1 is generally considered insecure now.
- AllowTcpForwarding Specifies whether Transmission Control Protocol (TCP) forwarding is permitted. The default is yes.
- X11Forwarding Specifies whether X11 forwarding is permitted. The argument must be yes or no. The default is no.
- ListenAddress Specifies the local address that the SSH daemon listens on. By default, OpenSSH will listen on both Internet Protocol version 4 (IPv4) and Internet Protocol version 6 (IPv6) sockets. But if you need to specify a particular interface address, you can tweak this directive.
User-specific SSH configuration information is stored in the user’s home directory within the ~/.ssh/ directory.
| Configuration File | Description |
| ~/.ssh/authorized_keys | Holds a list of authorized public keys for servers. When the client connects to a server, the server authenticates the client by checking its signed public key stored within this file. |
| ~/.ssh/id_dsa | Contains the DSA private key of the user. |
| ~/.ssh/id_dsa.pub | The DSA public key of the user. |
| ~/.ssh/id_rsa | The RSA private key used by ssh for version 2 of the SSH protocol. |
| ~/.ssh/id_rsa.pub | The RSA public key used by ssh for version 2 of the SSH protocol |
| ~/.ssh/identity | The RSA private key used by ssh for version 1 of the SSH protocol. |
| ~/.ssh/identity.pub | The RSA public key used by ssh for version 1 of the SSH protocol. |
| ~/.ssh/known_hosts | Contains DSA host keys of SSH servers accessed by the user. This file is very important for ensuring that the SSH client is connecting the correct SSH server. |
For SSH to be truly effective, using insecure connection protocols should be prohibited. Otherwise, a user’s password may be protected using SSH for one session, only to be captured later while logging in using Telnet. Some services to disable include telnet, rsh, rlogin, and vsftpd.
Key-Based Authentication
To improve the system security even further, you can enforce the key-based authentication by disabling the standard password authentication. To do so, open the /etc/ssh/sshd_config configuration file in a text editor, and change the PasswordAuthentication option as follows:
PasswordAuthentication no
To be able to use ssh, scp, or sftp to connect to the server from a client machine, generate an authorization key pair by following the steps below. Note that keys must be generated for each user separately.
Generating Key Pairs – To generate an RSA key pair for version 2 of the SSH protocol, follow these steps:
- Generate an RSA key pair by typing the following at a shell prompt:
~]$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/john/.ssh/id_rsa):
- Press Enter to confirm the default location (that is, ~/.ssh/id_rsa) for the newly created key.
- Enter a passphrase, and confirm it by entering it again when prompted to do so. For security reasons, avoid using the same password as you use to log in to your account
- Change the permissions of the ~/.ssh/ directory – ~]$ chmod 755 ~/.ssh
- Copy the content of ~/.ssh/id_rsa.pub into the ~/.ssh/authorized_keys on the machine to which you want to connect, appending it to its end if the file already exists.
- Change the permissions of the ~/.ssh/authorized_keys file using the following command –
~]$ chmod 644 ~/.ssh/authorized_keys
To generate an RSA key pair for version 1 of the SSH protocol, follow these steps:
- Generate an RSA key pair by typing the following at a shell prompt
~]$ ssh-keygen -t rsa1
Generating public/private rsa1 key pair.
Enter file in which to save the key (/home/john/.ssh/identity):
- Press Enter to confirm the default location (that is, ~/.ssh/identity) for the newly created key.
- Enter a passphrase, and confirm it by entering it again when prompted to do so. For security reasons, avoid using the same password as you use to log into your account.
After this, you will be presented with a message similar to this
Your identification has been saved in /home/john/.ssh/identity.
- Change the permissions of the ~/.ssh/ directory:
~]$ chmod 755 ~/.ssh
- Copy the content of ~/.ssh/identity.pub into the ~/.ssh/authorized_keys on the machine to which you want to connect, appending it to its end if the file already exists.
- Change the permissions of the ~/.ssh/authorized_keys file using the following command:
~]$ chmod 644 ~/.ssh/authorized_keys
The private key is for your personal use only, and it is important that you never give it to anyone.
Configuring ssh-agent
To store your passphrase so that you do not have to enter it each time you initiate a connection with a remote machine, you can use the ssh-agent authentication agent. To save your passphrase for a certain shell prompt, use the following command:
~]$ ssh-add
Enter passphrase for /home/john/.ssh/id_rsa:
When you log out, your passphrase will be forgotten. You must execute the command each time you log in to a virtual console or a terminal window.
Using the ssh Utility
ssh allows you to log in to a remote machine and execute commands there. It is a secure replacement for the rlogin, rsh, and telnet programs. Similarly to telnet, to log in to a remote machine named penguin.example.com, type the following command at a shell prompt:
~]$ ssh penguin.example.com
This will log you in with the same username you are using on a local machine. If you want to specify a different one, use a command in the ssh username@hostname form.
Apply for Linux Administration Certification Now!!
http://www.vskills.in/certification/Certified-Linux-Administrator