Cryptography, This is one of the few cryptographic methods that can be proven to be secure.

In a previous article from the Introduction to Information Security Fundamentals series , we learned the basic definitions of cryptography.

Do you remember that Morteza wanted to send a message to Jafar Bank, but because Javad might have overheard Pabamha, he had to use an encryption method to send his message in encrypted form.

To do this , we reviewed the surrogate encryption method and saw how this encryption could be broken using encryption analysis methods.

 In this article, we describe One Time Pad encryption. A cryptographic method that has been proven to be secure.

Morteza, who recently worked as a spy in Nazi Germany, wants to send an encrypted message to Jafar, who is in charge of his superior. He wants to use One Time Pad encryption to encrypt his message. Javad, a spy for the Soviet Union, also intends to eavesdrop on the message and crack the code.

To make our job easier, we consider only the first part of Morteza’s message. This message starts with the phrase heilhitler. To use One Time Pad encryption, we assign a binary code to each letter of the code.

Because in this example we are dealing with only 8 letters of the alphabet, we can assign a 3-bit code to each letter as follows.

These codes provide only a mapping of the alphabet to three-bit strings and should not be kept confidential. Using them here is something like using ASCII encoding.

In the previous article, we said that in a cryptographic method, there should be nothing secret other than the cryptographic key. We introduced this issue as the Karkhoff principle .

In this way, Morteza’s message (heilhitler phrase) becomes the following bit string:

001 000 010 100 001 010 111 100 000 101

–

How does One Time Pad encryption work?

Now Morteza has to encrypt his message using One Time Pad encryption. To do this, we need a key that is exactly the same length as the message. This key must be selected randomly. Morteza uses the following bit string as a key:

111 101 110 101 111 100 000 101 110 000

–

In the One Time Pad encryption method, to generate encrypted text or Cipher Text, we plain text with the XOR encryption key. One of the features of XOR operation is that:

a XOR b XOR b = a

For this reason, if the encrypted text (Cipher Text) is entered with the XOR encryption key, it will be the result of plain text operations. In this way, the encryption and decryption methods are exactly the same.

So Morteza’s message will be encrypted as follows:

Encrypted message means that the phrase srlhssthsr can be transmitted quite safely, without the listener of the message knowing anything about the content of the message.

The listener can only understand the length of the main message, but this problem can also be solved by using creative methods.

Jafar, who has the cryptographic key, repeats the same operation after receiving the message and obtains the main message.

If we decrypt the same encrypted text with another key, the simple message we get is completely different. Imagine using the following bit string as an encryption key to decrypt the srlhssthst message:

101 111 000 101 111 100 000 101 110 000

–

As you can see, the result is killhitler instead of heilhitler. Without knowing the key, any phrase with the same length can probably be exactly the same as the main message.

As a result, without knowing the key and holding the encrypted message, no guess can be made about the main message. This means that this encryption method is completely secure. But provided that each key is used only once.

Why is the One Time Pad encryption key disposable?

Suppose the two messages P1 and P2 are both encrypted with the K key.

C1 = P1 XOR K

C2 = P2 XOR K

C1 XOR C2 = P1 XOR K XOR P2 XOR K = P1 XOR P2

The above statement indicates that if the same cryptographic key is used twice, information about the original message can be found. In this case, it is enough to reveal only a part of one of the messages or guess correctly, so that the encryption is broken and more information about the main messages without a key is obtained.

For example, if both kite and like are both encrypted with a key:

The person listening to the messages can guess that the second and fourth letters of both messages are the same. Breaking the encryption by revealing the details of the messages can be as simple as solving the table.

Why can’t One Time Pad encryption be used for today’s applications?

We saw that the encryption key in the One Time Pad encryption method needs to be changed each time, and the length of this key should be the same size as the original message.

Choosing a key of this length is practically very challenging in today’s applications dealing with very large data, and transmitting a key of this size to any message is not safe to do.

Therefore, this method of cryptography, although it offers very good security, but can not be used in most applications today. But knowing this helps to understand the cryptographic methods used today.

Challenge your findings

At the end of the third article in the collection of information security basics,

it is not bad to review a little of what we have learned in these three articles.

If you are familiar with programming languages, you can implement successor cryptography or One Time Pad cryptography.

You can also think of creative ways to prevent message length from being revealed

in One Time Pad encryption and implement the way you think.

In the next article, we will look at the cryptographic methods used in the computer world today and learn how they work.

This document explains how Netscape uses RSA public key cryptography for Internet security. Netscape’s implementation of the Secure Sockets Layer (SSL) protocol employs the techniques discussed in this document.

RSA public key cryptography is widely used for authentication and encryption in the computer industry. Netscape has licensed RSA public key cryptography from RSA Data Security Inc. for use in its products, specifically for authentication.

Public key encryption is a technique that uses a pair of asymmetric keys for encryption and decryption. Each pair of keys consists of a public key and a private key. The public key is made public by distributing it widely. The private key is never distributed; it is always kept secret.

Data that is encrypted with the public key can be decrypted only with the private key. Conversely, data encrypted with the private key can be decrypted only with the public key. This asymmetry is the property that makes public key cryptography so useful.

Authentication is the process of verifying identity so that one entity can be sure that another entity is who it claims to be. In the following example involving Alice and Bob, public key cryptography is easily used to verify identity. The notation {something}key means that something has been encrypted or decrypted using key.

Suppose Alice wants to authenticate Bob. Bob has a pair of keys, one public and one private. Bob discloses to Alice his public key (the way he does this is discussed later). Alice then generates a random message and sends it to Bob:

Bob uses his private key to encrypt the message and returns the encrypted version to Alice:

Alice receives this message and decrypts it by using Bob’s previously published public key. She compares the decrypted message with the one she originally sent to Bob; if they match, she knows she’s talking to Bob. An imposter presumably wouldn’t know Bob’s private key and would therefore be unable to properly encrypt the random message for Alice to check.

BUT WAIT, THERE’S MORE

Unless you know exactly what you are encrypting, it is never a good idea to encrypt something with your private key and then send it to somebody else. This is because the encrypted value can be used against you (remember, only you could have done the encryption because only you have the private key).

So, instead of encrypting the original message sent by Alice, Bob constructs a message digest and encrypts that. A message digest is derived from the random message in a way that has the following useful properties:

• The digest is difficult to reverse. Someone trying to impersonate Bob couldn’t get the original message back from the digest.
• An impersonator would have a hard time finding a different message that computed to the same digest value.

By using a digest, Bob can protect himself. He computes the digest of the random message sent by Alice and then encrypts the result. He sends the encrypted digest back to Alice. Alice can compute the same digest and authenticate Bob by decrypting Bob’s message and comparing values.

GETTING CLOSER

The technique just described is known as a digital signature. Bob has signed a message generated by Alice, and in doing so he has taken a step that is just about as dangerous as encrypting a random value originated by Alice. Consequently, our authentication protocol needs one more twist: some (or all) of the data needs to be originated by Bob.

When he uses this protocol, Bob knows what message he is sending to Alice, and he doesn’t mind signing it. He sends the unencrypted version of the message first, “Alice, This Is Bob.” Then he sends the digested-encrypted version second. Alice can easily verify that Bob is Bob, and Bob hasn’t signed anything he doesn’t want to.

HANDING OUT PUBLIC KEYS

How does Bob hand out his public key in a trustworthy way? Let’s say the authentication protocol looks like this:

With this protocol, anybody can be Bob. All you need is a public and private key. You lie to Alice and say you are Bob, and then you provide your public key instead of Bob’s. Then you prove it by encrypting something with the private key you have, and Alice can’t tell you’re not Bob.

To solve this problem, the standards community has invented an object called a certificate. A certificate has the following content:

• The certificate issuer’s name
• The entity for whom the certificate is being issued (aka the subject)
• The public key of the subject
• Some time stamps

The certificate is signed using the certificate issuer’s private key. Everybody knows the certificate issuer’s public key (that is, the certificate issuer has a certificate, and so on…). Certificates are a standard way of binding a public key to a name.

By using this certificate technology, everybody can examine Bob’s certificate to see whether it’s been forged. Assuming that Bob keeps tight control of his private key and that it really is Bob who gets the certificate, then all is well. Here is the amended protocol:

Now when Alice receives Bob’s first message, she can examine the certificate, check the signature (as above, using a digest and public key decryption), and then check the subject (that is, Bob’s name) and see that it is indeed Bob. She can then trust that the public key is Bob’s public key and request Bob to prove his identity. Bob goes through the same process as before, making a message digest of his design and then responding to Alice with a signed version of it. Alice can verify Bob’s message digest by using the public key taken from the certificate and checking the result.

A bad guy – let’s call him Mallet – can do the following:

But Mallet can’t satisfy Alice in the final message. Mallet doesn’t have Bob’s private key, so he can’t construct a message that Alice will believe came from Bob.

EXCHANGING A SECRET

Once Alice has authenticated Bob, she can do another thing – she can send Bob a message that only Bob can decode:

The only way to find the secret is by decrypting the above message with Bob’s private key. Exchanging a secret is another powerful way of using public key cryptography. Even if the communication between Alice and Bob is being observed, nobody but Bob can get the secret.

This technique strengthens Internet security by using the secret as another key, but this time it’s a key to a symmetric cryptographic algorithm (such as DES, RC4, or IDEA). Alice knows the secret because she generated it before sending it to Bob. Bob knows the secret because Bob has the private key and can decrypt Alice’s message. Because they both know the secret, they can both initialize a symmetric cipher algorithm and then start sending messages encrypted with it. Here is a revised protocol:

How secret-key is computed is up to the protocol being defined, but it could simply be a copy of secret.

YOU SAID WHAT?

Mallet’s bag contains a few more tricks. Although Mallet can’t discover the secret that Alice and Bob have exchanged, he can interfere in their conversation by damaging it. For example, if Mallet is sitting between Alice and Bob, he can choose to pass most information back and forth unchanged but mangle certain messages (easy for him to do because he knows the protocol that Alice and Bob are speaking):

Mallet passes the data through without modification until Alice and Bob share a secret. Then Mallet gets in the way by garbling Bob’s message to Alice. By this point Alice trusts Bob, so she may believe the garbled message and try to act on it. Note that Mallet doesn’t know the secret – all he can do is damage the data encrypted with the secret key. Depending on the protocol, Mallet may not produce a valid message. Then again, he may get lucky.

To prevent this kind of damage, Alice and Bob can introduce a message authentication code (MAC) into their protocol. A MAC is a piece of data that is computed by using a secret and some transmitted data. The digest algorithm described above has just the right properties for building a MAC function that can defend against Mallet:

Because Mallet doesn’t know the secret, he can’t compute the right value for the digest. Even if Mallet randomly garbles messages, his chance of success is small if the digest data is large. For example, by using MD5 (a good cryptographic digest algorithm invented by RSA), Alice and Bob can send 128-bit MAC values with their messages. The odds of Mallet’s guessing the right MAC are approximately 1 in 18,446,744,073,709,551,616 – for all practical purposes, never.

Here is the sample protocol, revised yet again:

Mallet is in trouble now. He can garble messages all he wants, but the MAC computations will reveal him for the fraud he is. Alice or Bob can discover the bogus MAC value and stop talking. Mallet can no longer put words in Bob’s mouth.

WHEN WAS THAT SAID?

Last but not least to protect against is Mallet the Parrot. If Mallet is recording conversations, he may not understand them but he can replay them. In fact, Mallet can do some really nasty things sitting between Alice and Bob. The solution is to introduce random elements from both sides of the conversation.

Here is a short paper describing the UK government organisations involved in cryptography and information security (with a shamelessly biased view of their effectiveness).  This paper is an update of the one I published on the ‘ukcrypto’ list.

UK Government Cryptography Policy

June 1996 – The Conservative Party – Give them what’s good for them not what they need

When the previous government first published its policy on cryptography in June 1996 I provided a critique of the proposals and ran a web based survey of views on them with the following results.   These results suggested that the proposed policy was very unpopular with informed UK citizens.

I also ran a survey of views on the extent of acceptable government access to encrypted material on the UK National Information Infrastructure, with results that showed that there was only minority support for government access to encrypted information without the consent of the owner.

In order to promote debate on these issues I worked with Dr Ross Anderson (at Cambridge) and Paul Leyland (then at Oxford) to form the UK Cryptography Policy Discussion Group.

April 1998 – The Labour Government – Government Policy Set By The Civil Service

In April 1998, despite an ‘encryption friendly’ pre-election policy which promised no key escrow,

the Government announced a ‘key escrow’ policy that was little different to that of the previous government.  It is clear that they had swallowed the civil service propaganda and made a rapid reversal of their policy.  These revised proposals were announced by the Department of Trade and Industry on 27th April 1998 and my response to them is here.  This policy raised many objections from both industry and private citizens in the UK.

March to May 1999 – The Labour Government – Government Policy Set By Industry

In early 1999 the Government issued a further policy paper entitled “Building Confidence in Electronic Commerce” that was intended to be more acceptable to industry.  But while accepting the need for a voluntary licensing regime in place of a mandatory one,

this paper still advocated a ‘Trusted Third Party (TTP)’ approach to confidentiality services with key escrow.

This generated a storm of protest from both industry and the public.  My own comments are available here (it is interesting to note that this paper contains some surprising technical errors. See, for example, the discussion of key disclosure and self-incrimination and the description of ‘crypto-viral’ extortion).

The House of Commons Trade and Industry Committee considered this policy and heard a lot of evidence, the majority of which was critical.

They produced a report that suggested the need for significant changes in what was being proposed.

In consequence the Government had yet another rethink and announced in late March that it would drop the key escrow requirement provided industry came up with an acceptable alternative approach.

The Prime Minister commissioned a rapid high level study by the Performance and Innovation Unit of the Cabinet Office leading to a further report published in May 1999 under the heading “Encryption and Law Enforcement”.

I have worked with colleagues in Cyber-Rights and Cyber-Liberties (UK) to produce a response to this latest policy initiative, which makes some valuable proposals but also contains some significant weaknesses.

However, provided its weaknesses can be remedied, it may offer a sound basis on which to build.

Year 2000 – The Labour Government – A Policy For The People – Sadly No!

While export controls on encryption products have now been almost completely removed,

the UK government has passed a Bill in Parliament – the Regulation of Investigatory Powers Act – that includes provisions to allow a number of UK authorities to seize the encryption keys belonging to UK citizens. These powers can be used against entirely honest,

law abiding citizens who do not even have to be under suspicion.

The UK Government claims that the keys of honest citizens are not at risk because they will be able to offer the plaintext instead of keys

but the legislation does not give key owners any such rights.

While the UK Government has accepted that key owners should not have to hand over their keys without knowing that they be safe while in government hands,

it has repeatedly refused to provide the information that key owners need in order to make such an assessment.  In practice,

maintaining the safety and security of keys will be very difficult task and this will mean that those whose keys are seized

will have no choice but to assume that their security has been compromised as a result.

This legislation will also undermine the majority of the digital signatures offered by UK citizens

. Such signatures will be untrustworthy where the keys providing them are controlled by pass phrases that also control access to confidentiality keys.

In such situation the key owners cannot guarantee that they alone have access and this undermines the integrity of signatures made with their keys.

Other countries, most notably Germany and Ireland,

have explicitly rejected such measures and hence provide a better base for e-commerce development than the UK.

Export Controls on Cryptographic Products

A number of governments co-ordinate their export controls on cryptographic products through an international mechanism known as the Wassenaar Arrangement.   UK controls on cryptography are often justified by quoting this agreement but a careful consideration of its provisions shows that it should not be used to impede genuine civil transactions and trade.  But this is precisely the impact that these cryptographic export controls now have.  I have produced a paper that analyses the Wassenaar Agreement and shows that controls on civil cryptographic products are contrary to its stated objectives.

Here is a paper that was commissioned by the Foundation for Information Policy Research on export controls that I co-authored with Ian Brown and Nicholas Bohm.

The White Paper on Strategic Export Controls

In 1998 the UK government published a White Paper setting out its proposals for improving the operation of strategic export controls in response to the findings of the Scott Report.

This White Paper sets out a number of proposals for improving the effectiveness of export controls but also includes a proposal to extend the scope of such controls to include intangible goods,

that is, goods such as software transferred by electronic means.

While the proposals to improve the clarity of export control objectives are very welcome, the proposal to extend the scope of controls to intangible goods is a thoroughly bad idea.

In practice there is no well defined boundary that separates ‘intangible goods’ on the one hand and

‘ideas’ on the other and this means that once we give the government the ability to control intangible goods we are on a slippery slope which could easily end

with the government controlling the export of ideas as well.  This is a dangerous path to follow:

“I would rather be exposed to the inconveniences attending too much liberty than to those attending too small a degree of it.” –  Thomas Jefferson to Archibald Stuart, 1791.

Quite apart from the principles involved, the extension of controls to intangible goods could have an enormous and detrimental impact on research and development in the UK, much of which is now carried out in an international context.  If research and development teams in universities and industry need licenses in order to exchange ideas with their overseas colleagues we will very quickly find that high quality R&D will go elsewhere.  This is precisely what is happening in the United States where efforts to control cryptographic intangibles have simply resulted in companies setting up laboratories overseas.

The effect has thus been to export high-technology jobs and this is exactly the effect we can expect in the UK.

Ross Anderson has produced a paper expressing his position on the impact of these proposals on Universities.  I share his concerns and I have accordingly made my position known by sending an open letter to the relevant part of the DTI.

It appears that the prospects of direct UK legislation on intangible exports has now receded only to be replaced by similar plans for European Community legislation.

Cryptography Policy Principles

Cryptographic algorithms are the creations of mathematicians, scientists and engineers whose efforts should benefit the whole of society and not just the privileged few chosen by governments.

The actions of GCHQ and successive UK governments over the last 50 years to monopolise and control the use of cryptography using secret policies operated by unaccountable bodies is unjustified,

unethical and morally bankrupt.

It is a classic example of the abuse of power that always results

when excessive secrecy is combined with a lack of democratic accountability and control.

UK government policies on the control of cryptography must be arrived

at though informed public debate leading to a widespread consensus among informed and interested citizens that:

(1) any controls are truly in their interests as they judge them; and (2) not detrimental to the development of democracy and human freedom on a global scale.

In the absence (as now) of such a democratically derived policy I intend to work with other scientists and

engineers of like mind to ensure that any attempt by the UK

(or any other government) to control or limit the development,

publication, provision or use of cryptographic knowledge or technology will fail.

Since some may suggest that this is an anarchist stance

I will restate it as “I prefer democracy in place of anarchy but anarchy in place of dictatorship”.

Law Enforcement Access to Keys (LEAK) and to Encrypted Information

I am prepared to consider any direct evidence presented to show that UK law enforcement authorities are being hampered by encryption.

I have seen no evidence that this is a current problem of any significance.  Although there may be some future impact,

I believe that the positive benefits of the widespread deployment of cryptography

in crime prevention and detection will far outweigh any negative impact that this might have.

If there is any law enforcement access requirement it can only be to

encrypted information and not to the keys being used.

There are hence no circumstances in which I support any requirements for government or

law enforcement access to encryption keys.  I support the need for law enforcement authorities to be able to

use a ‘search warrant’ style of access to the decrypted text of encrypted material but not the keys being used.

Key Recovery

The need to back up cryptographic keys is highly application dependent and

requires a careful consideration of the consequences of key loss compared

with the additional risks involved in keeping spare copies of keys or the information involved.

It is important that the owners of information protected using encryption are entirely free

to decide for themselves how they wish to guard against the possibility of key loss or damage.

There is no case for products which make the strength of the primary cryptography which

they offer dependent in some way on the use of key recovery.

There is even less reason for making export approval dependent on the existence of key recovery mechanisms.  William Reinsch,

Head of the US Bureau of Export Administration

(speaking at a recent EPIC conference in Washington) characterised such policies as ‘neither efficient, nor fair,

but available’, a characterisation which well illustrates the moral bankruptcy involved.

Here is a paper I presented on Key Recovery (and Key Escrow) at the EPIC Cryptography Conference in Washington DC last year.

Key Escrow

I oppose all forms of key escrow that are designed to provide government or law enforcement access to encryption keys.  I have both ethical and technical objections to such schemes.

Although many democratic countries have institutions and approaches that can significantly limit and control government abuse of key escrow capabilities,

this is not more generally true and in many countries these would undoubtedly be used as a means of oppression.

If democratic countries implement such measures they then have no moral or

ethical basis on which to deny these facilities to governments that will use them against their own citizens.

The ability of encryption to allow people to interact with each other on

a global scale without fear of oppression by

their governments is just about the most potent capability mankind

has had for advancing democracy and human freedom on a global scale.

I consider it a tragedy that the United States in particular,

with its strong tradition of promoting democracy and human freedom,

should be seeking to deny this technology to those who most need it.

I support the conclusions of expert international cryptographers who

have assessed the risks of key escrow and concluded that they are very significant.

In particular I see no economic or technical basis for successful third party key escrow services.

In order to be economically sound such services will need to support many clients and

this involves holding critical security data in large,

network connected computer systems.

Designing and operating such computer systems to the levels of security this

would require is well beyond the current state of the art.

Although it is possible to reduce the risks by splitting keys between a number of separate computer systems,

the resulting services will then be prohibitively expensive and uneconomic to provide or use.

I thus believe that there are no sound commercial arguments for offering or using third party key escrow services. Third party key escrow is only necessary in order to meet government requirements for access to keys;

government efforts to promote such services as commercially

sound are simply attempts to meet their own requirements without having to foot the bill.

Duplicity is a piece of software which provides easy encrypted versioned remote backup of files requiring little of the remote server. It does this using GnuPG, tar, and rdiff. To transmit data it can use ssh/scp, local file access, rsync, ftp, and Amazon S3.

You also need to setup a passphrase. A passphrase is a sequence of words or other text used to control access to a computer system, program or data.

A passphrase is similar to a password in usage, but is generally longer for added security. Passphrases are often used to control both access to, and operation of, cryptographic programs and systems.

Passphrases are particularly applicable to systems that use the passphrase as an encryption key. I strongly recommend that you setup a passphrase for your ssh-keys.

Install duplicity on Debian / Ubuntu Linux

Open the terminal and type the following command (Red hat and friends see our previous faq “Install duplicity on RHEL/CentOS based systems” for more information):

$ sudo apt-get install duplicity

OR

# apt-get install duplicity

Sample outputs:

Reading package lists… Done

Building dependency tree

Reading state information… Done

The following extra packages will be installed:

librsync1 python-crypto python-gnupginterface python-paramiko

Suggested packages:

python-boto ncftp python-pexpect python-cloudfiles python-gdata tahoe-lafs

python-crypto-dbg python-crypto-doc

The following NEW packages will be installed:

duplicity librsync1 python-crypto python-gnupginterface python-paramiko

0 upgraded, 5 newly installed, 0 to remove and 0 not upgraded.

Need to get 1,735 kB of archives.

After this operation, 10.4 MB of additional disk space will be used.

Do you want to continue [Y/n]? y

Get:1 http://mirrors.kernel.org/debian/ stable/main librsync1 amd64 0.9.7-9 [72.1 kB]

Get:2 http://mirrors.kernel.org/debian/ stable/main python-gnupginterface all 0.3.2-9.1 [21.0 kB]

Get:3 http://mirrors.kernel.org/debian/ stable/main duplicity amd64 0.6.18-3 [309 kB]

Get:4 http://mirrors.kernel.org/debian/ stable/main python-crypto amd64 2.6-4 [524 kB]

Get:5 http://mirrors.kernel.org/debian/ stable/main python-paramiko all 1.7.7.1-3.1 [809 kB]

Fetched 1,735 kB in 6s (262 kB/s)

Selecting previously unselected package librsync1:amd64.

(Reading database … 36532 files and directories currently installed.)

Unpacking librsync1:amd64 (from …/librsync1_0.9.7-9_amd64.deb) …

Selecting previously unselected package python-gnupginterface.

Unpacking python-gnupginterface (from …/python-gnupginterface_0.3.2-9.1_all.deb) …

Selecting previously unselected package duplicity.

Unpacking duplicity (from …/duplicity_0.6.18-3_amd64.deb) …

Selecting previously unselected package python-crypto.

Unpacking python-crypto (from …/python-crypto_2.6-4_amd64.deb) …

Selecting previously unselected package python-paramiko.

Unpacking python-paramiko (from …/python-paramiko_1.7.7.1-3.1_all.deb) …

Processing triggers for man-db …

Processing triggers for python-support …

How do I create SSH keys?

To run automated backups, you must set password-less SSH connections using an SSH keys. Use ssh-keygen command to create ssh-keys:

ssh-keygen -t rsa

Skip a passphrase (not recommend)

If you trust your local system/server/latop/desktop do not enter a passphrase. Just hit enter twice and set an empty passphrase. See the following step-by-step guide for detailed information on setting up ssh keys:

Howto Linux / UNIX setup SSH with DSA public key authentication (password less login)

Howto use multiple SSH keys for password less login?

Setup a passphrase for ssh keys (recommend)

If you are paranoid, set a passphrase when prompted and install keychain to setup password less login:

$ sudo apt-get install keychain

Edit your ~/.bash_profile, enter:

vi $HOME/.bash_profile

Append the following keychain config directives:

Note –clear option is a security feature ##

/usr/bin/keychain –clear  $HOME/.ssh/id_rsa

source $HOME/.keychain/$HOSTNAME-sh

Save and close the file. See our faq: “keychain: Set Up Secure Passwordless SSH Access For Backup Scripts” for more information.

How do I create a GPG keys?

Install GNU privacy guard – a free PGP replacement:

# apt-get install gnupg

OR

$ sudo apt-get install gnupg

Type the following command to create a GPG key to encrypt backups:

# gpg –gen-key

Sample outputs:

gpg (GnuPG) 1.4.12; Copyright (C) 2012 Free Software Foundation, Inc.

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law.

gpg: keyring `/root/.gnupg/secring.gpg  created

Please select what kind of key you want:

(1) RSA and RSA (default)

(2) DSA and Elgamal

(3) DSA (sign only)

(4) RSA (sign only)

Your selection? 1

RSA keys may be between 1024 and 4096 bits long.

What keysize do you want? (2048) 4096

Requested keysize is 4096 bits

Please specify how long the key should be valid.

0 = key does not expire

<n>  = key expires in n days

<n>w = key expires in n weeks

<n>m = key expires in n months

<n>y = key expires in n years

Key is valid for? (0) 0

Key does not expire at all

Is this correct? (y/N) y

You need a user ID to identify your key; the software constructs the user ID

from the Real Name, Comment and Email Address in this form:

Heinrich Heine (Der Dichter) <heinrichh@duesseldorf.de>

Real name: Home Nas Server

Email address: root@nas01

Comment: Home Nas Server Backup

You selected this USER-ID:

Home Nas Server (Home Nas Server Backup) <root@nas01>

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O

You need a Passphrase to protect your secret key.

To list your gpg keys, run:

# gpg –list-keys

Sample outputs:

/root/.gnupg/pubring.gpg

pub   4096R/4AABBCC7 2013-10-04

uid                  Home Nas Server (Home Nas Server Backup) <root@nas01>

sub   4096R/12345678 2013-10-04

You need to note down the public key 4AABBCC7.

How do I backup files?

The following example use scp to backup /home/nixcraft/ to ~/backups on the cloud.example.com system:

duplicity /home/nixcraft/ scp://user@cloud.example.com/backups

Exclude the files from backup

The following command will backup the / (whole root file system) but excludes /tmp, /proc, /nas, /jails, and /mnt directories from backup:

duplicity –exclude /tmp/ –exclude /proc/ –exclude /nas/ \

–exclude /jails/ –exclude /mnt/ / scp://user@cloud.example.com/backups

Include the files in backup

The following command will backup only the /home/, /root/, /etc/, and /var/spool/cron/ directories under root (/) file system using the –include option:

duplicity –include /home/ –include /root –include /etc/ \

–include /var/spool/cron/ –exclude  **  / scp://user@cloud.example.com/backups

Encrypted backup commands

When backing up, encrypt to the given public key, instead of using symmetric (traditional) encryption. You need to use the –encrypt-key option as follows. To find out your gpg key-id use the following command:

gpg –list-keys

Full backup duplicity command

To make full encrypted backup, enter:

duplicity full –encrypt-key= 4AABBCC7  /home/nixcraft/ scp://userNameHere@cloud.example.com/backups

Incremental backup duplicity command

To make incremental encrypted backup, enter:

duplicity incr –encrypt-key= 4AABBCC7  /home/nixcraft/ scp://userNameHere@cloud.example.com/backups

List the files stored in the archive

To see the files currently backed up in the archive, enter:

duplicity list-current-files –encrypt-key= 4AABBCC7  scp://userNameHere@cloud.example.com/backups

Verify backup duplicity command

You can verify backup with the following command:

duplicity verify –encrypt-key= 4AABBCC7  scp://userNameHere@cloud.example.com/backups /home/nixcraft

Rotate backup duplicity command

You can delete all backup sets older than the given time. Now suppose you want to retain 60 days of backup and remove files older than 60 days, enter:

duplicity remove-older-than 60D –encrypt-key= 4AABBCC7  –force scp://userNameHere@cloud.example.com/backups

Pass the remove-all-but-n-full count to delete all backups sets that are older than the count:th last full backup. In other words, keep the last count full backups and associated incremental ets). The count must be larger than zero. A value of 1 means that only the single most recent backup chain will be kept. Note that the option –force will be needed to delete the files rather than just list them.

duplicity remove-all-but-n-full 10 –encrypt-key= 4AABBCC7  –force scp://userNameHere@cloud.example.com/backups

Restore (recover) last backup duplicity command

Now suppose you accidentally delete /home/nixcraft/ and want to restore it the way it was at the time of last backup, enter:

mkdir /home/nixcraft/

duplicity –encrypt-key= 4AABBCC7  scp://userNameHere@cloud.example.com/backups /home/nixcraft/

Restore (recover) specific file duplicity command

If you wanted to restore just the file “Documents/resume.doc” in /home/nixcraft/ as it was seven days ago into /home/nixcraft/Documents, type:

duplicity -t 7D –file-to-restore= Documents/resume.doc  –encrypt-key= 4AABBCC7  scp://userNameHere@cloud.example.com/backups /home/nixcraft/Documents

Cleaning up backups

You can delete the extraneous duplicity files. Non-duplicity files, or files in complete data sets will not be deleted. This should only be necessary after a duplicity session fails or is aborted prematurely. Note that the –force option will be needed to delete the files rather than just list them:

duplicity cleanup –force –encrypt-key= 4AABBCC7  scp://userNameHere@cloud.example.com/backups

Putting it all together

A sample shell script:

#!/bin/bash

# A simple backup script wrapper for duplicity.

# Author – nixCraft <www.cyberciti.biz> under GPL v2+

# —————————————————–

Define VARS ##

_gpg_key= 4AABBCC7

_target= scp://userNameHere@cloud.example.com/backups

_duplicity= /usr/bin/duplicity

_src= /home/nixcraft/

Unlock ssh/scp/sftp ##

source $HOME/.keychain/$HOSTNAME-sh

Cleanup ##

$_duplicity –force –encrypt-key= ${_gpg_key}  ${_target}

Rotate old backups than 60 days ##

$_duplicity remove-older-than 60D –encrypt-key= ${_gpg_key}  ${_target}

Backup our home sweet home i.e. /home/nixcraft/ ##

Note: full backup if older than 60 day else do incremental backup ###

$_duplicity ${_src} –encrypt-key= ${_gpg_key}  –full-if-older-than 60D ${_target}

Setup cron job as follows:

@daily /path/to/your/awesome/backup.script.sh

Recommend readings:

Man pages: ssh(1),scp(1),duplicity(1),cron(8),bash(1)

duplicity home page

know how to cange a passphrase for openssh using ssh-keygen command. How do I change a GPG encryption key’s passphrase on Linux or Unix like operating systems? How do I change the passphrase of the secret key using gpg?

gpg is the OpenPGP part of the GNU Privacy Guard (GnuPG). It is a tool to provide digital encryption and signing services using the OpenPGP standard. You can use the gpg command for complete key management including setting up keys, change key passphrase, list keys and much more.

Change the passphrase of the secret key

The syntax is:

gpg –edit-key Your-Key-ID-Here

gpg> passwd

gpg> save

You need type the passwd command followed by the save command at gpg> prompt to change the passphrase for your key-ID.

Examples

First, list your keys with the following command:

gpg –list-keys

Sample outputs:

/root/.gnupg/pubring.gpg

pub   4096R/9AABBCD8 2013-10-04

uid                  Home Nas Server (Home Nas Server Backup)

sub   4096R/149D60C7 2013-10-04

You need to note down the public key 9AABBCD8. Next, type the following command:

gpg –edit-key 9AABBCD8

Sample outputs:

gpg (GnuPG) 1.4.12; Copyright (C) 2012 Free Software Foundation, Inc.

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law.

Secret key is available.

pub  4096R/9AABBCD8  created: 2013-10-04  expires: never       usage: SC

trust: ultimate      validity: ultimate

sub  4096R/149D60C7  created: 2013-10-04  expires: never       usage: E

[ultimate] (1). Home Nas Server (Home Nas Server Backup)

gpg>

Type the passwd command at gpg> prompt to change the passphrase:

gpg> passwd

You need to supply old passphrase to unlock the secret key:

Key is protected.

You need a passphrase to unlock the secret key for

user:  Home Nas Server (Home Nas Server Backup)

4096-bit RSA key, ID 9AABBCD8, created 2013-10-04

Enter passphrase: TYPE-YOUR-OLD-PASSPHRASE-HERE

Finally, enter the new passphrase:

Enter the new passphrase for this secret key.

Enter passphrase: TYPE-YOUR-new-PASSPHRASE-HERE

Repeat passphrase: again-TYPE-YOUR-new-PASSPHRASE-HERE

To save all changes to the key rings and quit, type save at gpg> prompt:

gpg> save

For more information read gpg(1) man page.

operate a small web site on Cloud server powered by CentOS Linux v6.4. I would like to encrypt my site’s information and create a more secure connection. How do I create a self-signed SSL certificate on Nginx for CentOS/Fedora or Red Hat Enterprise Linux based server?

The ssl encrypts your connection. For example, a visit to https://www.cyberciti.biz/ result into the following:

All pages were encrypted before being transmitted over the Internet.

Encryption makes it very difficult to unauthorized person to view information traveling between client browser and nginx server.

A note about a self-signed certificates vs a third party issued certificates

Fig.01: Cyberciti.biz connection encrypted and verified by a third party CA called GeoTrust, Inc.

Usually, an SSL certificate issued by a third party. It provides privacy and security between two computers (client and server) on a public network by encrypting traffic. CA (Certificate Authorities) may issue you a SSL certificate that verify the organizational identity (company name), location, and server details.

A self-signed certificate encrypt traffic between client (browser) and server. However, it can not verify the organizational identity. You are not depend upon third party to verify your location and server details.

Our sample setup

Domain name: theos.in

Directory name: /etc/nginx/ssl/theos.in

SSL certificate file for theos.in: /etc/nginx/ssl/theos.in/self-ssl.crt

ssl certificate key for theos.in: /etc/nginx/ssl/theos.in/self-ssl.key

Nginx configuration file for theos.in: /etc/nginx/virtual/theos.in.conf

Step #1: Make sure SSL aware nginx installed

Simply type the following command to verify nginx version and feature:

$ /usr/sbin/nginx -V

Sample outputs

nginx version: nginx/1.4.3

built by gcc 4.4.7 20120313 (Red Hat 4.4.7-3) (GCC)

TLS SNI support enabled

configure arguments: –prefix=/etc/nginx –sbin-path=/usr/sbin/nginx –conf-path=/etc/nginx/nginx.conf

…

….

..

If nginx is not installed, type the following command to download and install nginx using yum command:

# yum install nginx

See how to install Nginx web server On CentOS Linux 6 or Red Hat Enterprise Linux 6 using yum command for more information.

Step #2: Create a directory

Type the following mkdir command to create a directory to store your ssl certificates:

# mkdir -p /etc/nginx/ssl/theos.in

Use the following cd command to change the directory:

# cd /etc/nginx/ssl/theos.in

Step #3: Create an SSL private key

To generate an SSL private key, enter:

# openssl genrsa -des3 -out self-ssl.key 1024

OR better try 2048 bit key:

# openssl genrsa -des3 -out self-ssl.key 2048

Sample outputs:

Generating RSA private key, 1024 bit long modulus

…++++++

……………++++++

e is 65537 (0x10001)

Enter pass phrase for self-ssl.key: Type-Your-PassPhrase-Here

Verifying – Enter pass phrase for self-ssl.key: Retype-Your-PassPhrase-Here

Warning: Make sure you remember passphrase. This passphrase is required to access your SSL key while generating csr or starting/stopping ssl.

Step #4: Create a certificate signing request (CSR)

To generate a CSR, enter:

# openssl req -new -key self-ssl.key -out self-ssl.csr

Sample outputs:

Enter pass phrase for self-ssl.key: Type-Your-PassPhrase-Here

You are about to be asked to enter information that will be incorporated

into your certificate request.

What you are about to enter is what is called a Distinguished Name or a DN.

There are quite a few fields but you can leave some blank

For some fields there will be a default value,

If you enter  . , the field will be left blank.

Country Name (2 letter code) [XX]:IN

State or Province Name (full name) []:Delhi

Locality Name (eg, city) [Default City]:New Delhi

Organization Name (eg, company) [Default Company Ltd]:nixCraft LTD

Organizational Unit Name (eg, section) []:IT

Common Name (eg, your name or your server s hostname) []:theos.in

Email Address []:webmaster@nixcraft.com

Please enter the following  extra  attributes

to be sent with your certificate request

A challenge password []:

An optional company name []:

Step #5: Remove passphrase for nginx (optional)

You can remove passphrase from self-ssl.key for nginx server, enter:

# cp -v self-ssl.{key,original}

# openssl rsa -in self-ssl.original -out self-ssl.key

# rm -v self-ssl.original

Sample outputs:

Enter pass phrase for self-ssl.original: Type-Your-PassPhrase-Here

writing RSA key

Step #6: Create certificate

Finally, generate SSL certificate i.e. sign your SSL certificate with your own .csr file for one year:

# openssl x509 -req -days 365 -in self-ssl.csr -signkey self-ssl.key -out self-ssl.crt

Sample outputs:

Signature ok

subject=/C=IN/ST=Delhi/L=New Delhi/O=nixCraft LTD/OU=IT/CN=theos.in/emailAddress=webmaster@nixcraft.com

Getting Private key

Step #7: Configure the Certificate for nginx

Edit /etc/nginx/virtual/theos.in.conf, enter:

# vi /etc/nginx/virtual/theos.in.conf

The general syntax is as follows for nginx SSL configuration:

server {

#for ipv4

listen 443 ssl http2;

#for ipv6

#listen [::]:443 ssl http2;

ssl_certificate      /path/to/self-ssl.crt;

ssl_certificate_key  /path/to/self-ssl.key;

server_name theos.in;

location / {

….

…

….

}

}

Here is my sample config for theos.in:

server {

###########################[Note]##############################

## Note: Replace IP and server name as per your actual setup ##

###############################################################

## IP:Port and server name

listen 75.126.153.211:443 ssl http2;

server_name theos.in;

## SSL settings

ssl_certificate /etc/nginx/ssl/theos.in/self-ssl.crt;

ssl_certificate_key /etc/nginx/ssl/theos.in/self-ssl.key;

## SSL caching/optimization

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

ssl_ciphers  ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS ;

ssl_prefer_server_ciphers on;

ssl_prefer_server_ciphers on;

ssl_session_cache shared:SSL:50m;

ssl_session_timeout 1d;

ssl_session_tickets off;

## SSL log files

access_log /var/log/nginx/theos.in/ssl_theos.in_access.log;

error_log /var/log/nginx/theos.in/ssl_theos.in_error.log;

## Rest of server config goes here

location / {

proxy_set_header        Accept-Encoding     ;

proxy_set_header        Host              $http_host;

proxy_set_header        X-Forwarded-By    $server_addr:$server_port;

proxy_set_header        X-Forwarded-For   $remote_addr;

proxy_set_header        X-Forwarded-Proto $scheme;

proxy_set_header        X-Real-IP               $remote_addr;

proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504;

## Hey, ADD YOUR location / specific CONFIG HERE ##

## STOP: YOUR location / specific CONFIG HERE ##

}

}

Step #8: Restart/reload nginx

Type the following command

# /usr/sbin/nginx -t

Sample outputs:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok

nginx: configuration file /etc/nginx/nginx.conf test is successful

To gracefully restart/reload nginx server, type the following command:

# /etc/init.d/nginx reload

OR

# /usr/sbin/nginx -s reload

OR

# service nginx reload

Step #9: Open TCP HTTPS port # 443

Type the following command to open port # 443 for everyone:

# /sbin/iptables -A INPUT -m state –state NEW -p tcp –dport 443 -j ACCEPT

Save new firewall settings:

# service iptables save

See how to setup firewall for a web server for more information.

Step 10: Test it

Fire a browser and type the following url:

https://theos.in/

Sample outputs:

Fig.02: SSL connection is not verified due to self-signed certificate. Click the “Add Exception” button to continue.

Step 11: Verify SSL certificats

You can verify SSL Certificate using the following command:

# openssl verify pem-file

# openssl verify self-ssl.crt

See also

See how to verify and diagnosis SSL certification installation from a Linux / UNIX shell prompt.

Man pages: openssl(1),nginx(8)

This entry is 10 of 10 in the CentOS / RHEL nginx Reverse Proxy Tutorial series. Keep reading the rest of the series:

CentOS / Redhat Linux: Install Keepalived To Provide IP Failover For Web Cluster

CentOS / Redhat: Install nginx As Reverse Proxy Load Balancer

Handling nginx Failover With KeepAlived

nginx: Setup SSL Reverse Proxy (Load Balanced SSL Proxy)

mod_extforward: Lighttpsd Log Clients Real IP Behind Reverse Proxy / Load Balancer

HowTo: Merge Apache / Lighttpsd / Nginx Server Log Files

Linux nginx: Chroot (Jail) Setup

HowTo: SPDY SSL Installation and Configuration

Install Nginx Using Yum Command on CentOS/RHEL

Create a Self-Signed SSL Certificate on Nginx

In SSH for Linux/Unix, how do I set up public key authentication?

I am assuming that you are using Linux or Unix-like server and client with the following software:

OpenSSH SSHD server

OpenSSH ssh client and friends on Linux (Ubuntu, Debian, {Free,Open,Net}BSD, RHEL, CentOS, MacOS/OSX, AIX, HP-UX and co).

What is a public key authentication?

OpenSSH server supports various authentication schema. The two most popular are as follows:

Passwords based authentication

Public key based authentication. It is an alternative security method to using passwords. This method is recommended on a VPS, cloud, dedicated or even home based server.

How to set up SSH keys

Steps to setup secure ssh keys:

Create the key pair using ssh-keygen command.

Copy and install the public key using ssh-copy-id command.

Add yourself to sudo admin account.

Disable the password login for root account.

Let us see all steps in details.

How do I set up public key authentication?

You must generate both a public and a private key pair. For example:

Fig.01: Our sample setup

Where,

server1.cyberciti.biz – You store your public key on the remote hosts and you have an accounts on this Linux/Unix based server.

client1.cyberciti.biz – Your private key stays on the desktop/laptop/ computer (or local server) you use to connect to server1.cyberciti.biz server. Do not share or give your private file to anyone.

In public key based method you can log into remote hosts and server, and transfer files to them, without using your account passwords.

Feel free to replace server1.cyberciti.biz and client1.cyberciti.biz names with your actual setup. Enough talk, let’s set up public key authentication. Open the Terminal and type following commands if .ssh directory does not exists:

mkdir -p $HOME/.ssh

chmod 0700 $HOME/.ssh

#1: Create the key pair

On the computer (such as client1.cyberciti.biz), generate a key pair for the protocol.

ssh-keygen -t rsa

Sample outputs:

Generating public/private rsa key pair.

Enter file in which to save the key (/Users/vivek/.ssh/id_rsa):

Enter passphrase (empty for no passphrase):

And Enter same passphrase again:

Your identification has been saved in /Users/vivek/.ssh/id_rsa.

Your public key has been saved in /Users/vivek/.ssh/id_rsa.pub.

The key fingerprint is:

80:5f:25:7c:f4:90:aa:e1:f4:a0:01:43:4e:e8:bc:f5 vivek@desktop01

The key s randomart image is:

+–[ RSA 2048]—-+

| oo    …+.     |

|.oo  .  .ooo     |

|o .o. . .o  .    |

| o …+o.        |

|  o .=.=S        |

| .  .Eo .        |

+—————–+

You need to set the Key Pair location and name. I recommend you use the default location if you do not yet have another key there, for example: $HOME/.ssh/id_rsa. You will be prompted to supply a passphrase (password) for your private key. I suggest that you setup a passphrase when prompted. You should see two new files in $HOME/.ssh/ directory:

$HOME/.ssh/id_rsa– contains your private key.

$HOME/.ssh/id_rsa.pub – contain your public key.

Optional syntax for advance users

The following syntax specifies the 4096 of bits in the RSA key to creation (default 2048):

$ ssh-keygen -t rsa -b 4096 -f ~/.ssh/vps-cloud.web-server.key -C  My web-server key

Where,

-t rsa : Specifies the type of key to create. The possible values are “rsa1” for protocol version 1 and “dsa”, “ecdsa”, “ed25519”, or “rsa” for protocol version 2.

-b 4096 : Specifies the number of bits in the key to create

-f ~/.ssh/vps-cloud.web-server.key : Specifies the filename of the key file.

-C  My web-server key  : Set a new comment.

#2: Install the public key in remote server

Use scp or ssh-copy-id command to copy your public key file (e.g., $HOME/.ssh/id_rsa.pub) to your account on the remote server/host (e.g., nixcraft@server1.cyberciti.biz). To do so, enter the following command on your client1.cyberciti.biz:

ssh-copy-id -i $HOME/.ssh/id_rsa.pub user@server1.cyberciti.biz

OR just copy the public key in remote server as authorized_keys in ~/.ssh/ directory:

scp $HOME/.ssh/id_rsa.pub user@server1.cyberciti.biz:~/.ssh/authorized_keys

A note about appending the public key in remote server

On some system ssh-copy-id command may not be installed, so use the following commands (when prompted provide the password for remote user account called vivek) to install and append the public key:

First create .ssh directory on server ##

ssh vivek@server1.cyberciti.biz  umask 077; test -d .ssh || mkdir .ssh

cat local id.rsa.pub file and pipe over ssh to append the public key in remote server ##

cat $HOME/.ssh/id_rsa.pub | ssh vivek@server1.cyberciti.biz  cat >> .ssh/authorized_keys

#3: Test it (type command on client1.cyberciti.biz)

The syntax is:

ssh user@server1.cyberciti.biz

Or copy a text file called foo.txt:

scp foo.txt user@server1.cyberciti.biz:/tmp/

You will be prompted for a passphrase. To get rid of passphrase whenever you log in the remote host, try ssh-agent and ssh-add commands.

What are ssh-agent and ssh-add, and how do I use them?

To get rid of a passphrase for the current session, add a passphrase to ssh-agent and you will not be prompted for it when using ssh or scp/sftp/rsync to connect to hosts with your public key. The syntax is as follows:

eval $(ssh-agent)

Type the ssh-add command to prompt the user for a private key passphrase and adds it to the list maintained by ssh-agent command:

ssh-add

Enter your private key passphrase. Now try again to log into user@server1.cyberciti.biz and you will not be prompted for a password:

ssh user@server1.cyberciti.biz

#4: Disable the password based login on a server

Login to your server, type:

client commands ##

eval $(ssh-agent)

ssh-add

ssh user@server1.cyberciti.biz

Edit /etc/ssh/sshd_config on server1.cyberciti.biz using a text editor such as nano or vim:

Warning: Make sure you add yourself to sudoers files. Otherwise you will not able to login as root later on. See “How To Add, Delete, and Grant Sudo Privileges to Users on a FreeBSD Server” for more info.

$ sudo vim /etc/ssh/sshd_config

OR directly jump to PermitRootLogin line using a vim text editor:

$ sudo vim +/PermitRootLogin /etc/ssh/sshd_config

Find PermitRootLogin and set it as follows:

PermitRootLogin no

Save and close the file. I am going to add a user named vivek to sudoers on Ubuntu Linux:

# adduser vivek

Finally, reload/restart the sshd server, type command as per your Linux/Unix version:

CentOS/RHEL/Fedora (older version) Linux server reload sshd ##

sudo service sshd reload

CentOS/RHEL/Fedora (latest version i.e. systemd based) Linux server reload sshd ##

sudo systemctl reload sshd

Debian/Ubuntu Linux (older version) server reload sshd ##

sudo /etc/init.d/ssh reload

Debian/Ubuntu Linux (systemd based latest) server reload sshd ##

sudo systemctl reload ssh

Generic Unix method to reload sshd ##

sudo kill -HUP cat /var/run/sshd.pid

OR

sudo kill -HUP $(cat /var/run/sshd.pid)

#5: How to add or replace a passphrase for an existing private key?

To to change your passphrase type the following command:

ssh-keygen -p

#6: How to backup an existing private/public key?

Just copy files to your backup server or external USB pen/hard drive:

Copy files to  home based nas server ##

rsync -avr $HOME/.ssh user@home.nas-server:/path/to/encrpted/nas/partition/

Copy files to  usb pen drive mounted at /mnt/usb ##

cp -avr $HOME/.ssh/ /mnt/usb/backups/

How do I protect my ssh keys

Always use a strong passphrase.

Do not share your private keys anywhere online or store in insecure cloud storage.

Restrict privileges of the account.

How do I create and setup an OpenSSH config file to create shortcuts for servers I frequently access?

See how to create and use an OpenSSH ssh_config file for more info.

See also

keychain: Set Up Secure Passwordless SSH Access For Backup Scripts

Ubuntu / Debian Linux Server Install Keychain SSH Key Manager For OpenSSH

Man pages – ssh(1),ssh-agent(1),ssh-add(1),ssh-keygen(1)

And, there you have it, ssh set up with public key based authentication for Linux or Unix-like systems.

n 19th March 2015, multiple high and moderate severity level vulnerabilities released in OpenSSL, a Secure Sockets Layer toolkit used in a Linux and Unix-like systems. How can I fix these vulnerabilities on a CentOS/RHEL/Ubuntu and Debian Linux based server for OpenSSL versions 1.0.2a, 1.0.1m, 1.0.0r, and 0.9.8zf.? How do I verify that my Linux server has been fixed against the OpenSSL vulnerability?

A serious security problem has been found and patched in the OpenSSL Library. Multiple vulnerabilities have been discovered in OpenSSL on 19/March/2015. The Common Vulnerabilities and exposures project identifies the following issues:

OpenSSL 1.0.2 ClientHello sigalgs DoS (CVE-2015-0291) – Severity: High

Reclassified: RSA silently downgrades to EXPORT_RSA [Client] (CVE-2015-0204) – Severity: High

Multiblock corrupted pointer (CVE-2015-0290) – Severity: Moderate

Segmentation fault in DTLSv1_listen (CVE-2015-0207) – Severity: Moderate

Segmentation fault in ASN1_TYPE_cmp (CVE-2015-0286) – Severity: Moderate

Segmentation fault for invalid PSS parameters (CVE-2015-0208) – Severity: Moderate

ASN.1 structure reuse memory corruption (CVE-2015-0287) – Severity: Moderate

PKCS7 NULL pointer dereferences (CVE-2015-0289) – Severity: Moderate

Base64 decode (CVE-2015-0292) – Severity: Moderate

DoS via reachable assert in SSLv2 servers (CVE-2015-0293) – Severity: Moderate

Empty CKE with client auth and DHE (CVE-2015-1787) – Severity: Moderate

Handshake with unseeded PRNG (CVE-2015-0285) – Severity: Low

Use After Free following d2i_ECPrivatekey error (CVE-2015-0209) Severity: Low

X509_to_X509_REQ NULL pointer deref (CVE-2015-0288) Severity: Low

How bad will this actually be?

It is not bad as the heartbleed openssl bug disclosed in April 2014 in the OpenSSL cryptography library. But, new bug can cause “Denial of Service” and crash your services. It is good security practice, to quickly apply the patched version on your system and restart the affected services.

How to find openssl version on a Linux?

The syntax is as follows:

Find openssl version on a CentOS/RHEL/SL/Fedora Linux

openssl version

or ##

sudo yum list installed openssl

Sample outputs:

Fig.01: How to RHEL/CentOS/Fedora Linux Find OpenSSL Version Command

Find openssl version on a Debian/Ubuntu Linux

openssl version

or ##

sudo dpkg -l | egrep   ^ii.*openssl

Sample outputs:

Fig.02: How to Debian/Ubuntu Linux Find OpenSSL Version Command

A list of affected Linux distros

I recommend that you upgrade your openssl packages ASAP to avoid any security issues on both client and server systems powered by Linux based distro.

RHEL version 6.x

RHEL version 7.x

CentoS Linux version 6.x

CentoS Linux version 7.x

Debian Linux stable (wheezy) 7.x

Ubuntu Linux 14.10

Ubuntu Linux 14.04 LTS

Ubuntu Linux 12.04 LTS

Ubuntu Linux 10.04 LTS

How to patch on a Linux?

Type the following commands as per your distro version/type:

how do I find out my distro version? ##

lsb_release -a

or use ##

cat /etc/*-release

Sample outputs:

Gif 01: HowTo: Find Out My Linux Distribution Name and Version

CentOS/RHEL/Fedora Linux

Type the following yum command to patch openssl as root user to patch openssl:

sudo yum clean all

To install the updates, use the yum command as follows:

sudo yum update

To only update the OpenSSL package and its dependencies, use the following yum command:

sudo yum update openssl

Sample outputs:

Loaded plugins: auto-update-debuginfo, protectbase, rhnplugin, security

This system is receiving updates from RHN Classic or RHN Satellite.

Setting up Update Process

epel-debuginfo/metalink                                  |  13 kB     00:00

rhel-x86_64-server-6                                     | 1.5 kB     00:00

rhel-x86_64-server-6/primary                             |  21 MB     00:05

rhel-x86_64-server-6                                                14680/14680

rhel-x86_64-server-6-debuginfo                           | 1.3 kB     00:00

rhel-x86_64-server-6-debuginfo/primary                   | 1.1 MB     00:00

rhel-x86_64-server-6-debuginfo                                        5939/5939

rhel-x86_64-server-optional-6                            | 1.5 kB     00:00

rhel-x86_64-server-optional-6/primary                    | 2.0 MB     00:00

rhel-x86_64-server-optional-6                                         8239/8239

rhel-x86_64-server-optional-6-debuginfo                  | 1.3 kB     00:00

rhel-x86_64-server-optional-6-debuginfo/primary          | 681 kB     00:00

rhel-x86_64-server-optional-6-debuginfo                               3571/3571

0 packages excluded due to repository protections

Resolving Dependencies

–> Running transaction check

—> Package openssl.x86_64 0:1.0.1e-30.el6_6.5 will be updated

–> Processing Dependency: openssl = 1.0.1e-30.el6_6.5 for package: openssl-devel-1.0.1e-30.el6_6.5.x86_64

—> Package openssl.x86_64 0:1.0.1e-30.el6_6.7 will be an update

–> Running transaction check

—> Package openssl-devel.x86_64 0:1.0.1e-30.el6_6.5 will be updated

—> Package openssl-devel.x86_64 0:1.0.1e-30.el6_6.7 will be an update

–> Finished Dependency Resolution

Dependencies Resolved

================================================================================

Package          Arch      Version               Repository               Size

================================================================================

Updating:

openssl          x86_64    1.0.1e-30.el6_6.7     rhel-x86_64-server-6    1.5 M

Updating for dependencies:

openssl-devel    x86_64    1.0.1e-30.el6_6.7     rhel-x86_64-server-6    1.2 M

Transaction Summary

================================================================================

Upgrade       2 Package(s)

Total download size: 2.7 M

Is this ok [y/N]: n

Exiting on user Command

[root@txvip1 ~]#

[root@txvip1 ~]# yum update openssl

Loaded plugins: auto-update-debuginfo, protectbase, rhnplugin, security

This system is receiving updates from RHN Classic or RHN Satellite.

Setting up Update Process

0 packages excluded due to repository protections

Resolving Dependencies

–> Running transaction check

—> Package openssl.x86_64 0:1.0.1e-30.el6_6.5 will be updated

–> Processing Dependency: openssl = 1.0.1e-30.el6_6.5 for package: openssl-devel-1.0.1e-30.el6_6.5.x86_64

—> Package openssl.x86_64 0:1.0.1e-30.el6_6.7 will be an update

–> Running transaction check

—> Package openssl-devel.x86_64 0:1.0.1e-30.el6_6.5 will be updated

—> Package openssl-devel.x86_64 0:1.0.1e-30.el6_6.7 will be an update

–> Finished Dependency Resolution

Dependencies Resolved

============================================================================================

Package             Arch         Version                  Repository                  Size

============================================================================================

Updating:

openssl             x86_64       1.0.1e-30.el6_6.7        rhel-x86_64-server-6       1.5 M

Updating for dependencies:

openssl-devel       x86_64       1.0.1e-30.el6_6.7        rhel-x86_64-server-6       1.2 M

Transaction Summary

============================================================================================

Upgrade       2 Package(s)

Total download size: 2.7 M

Is this ok [y/N]: y

Downloading Packages:

(1/2): openssl-1.0.1e-30.el6_6.7.x86_64.rpm                          | 1.5 MB     00:00

(2/2): openssl-devel-1.0.1e-30.el6_6.7.x86_64.rpm                    | 1.2 MB     00:00

Total                                                       6.4 MB/s | 2.7 MB     00:00

Running rpm_check_debug

Running Transaction Test

Transaction Test Succeeded

Running Transaction

Updating   : openssl-1.0.1e-30.el6_6.7.x86_64                                         1/4

Updating   : openssl-devel-1.0.1e-30.el6_6.7.x86_64                                   2/4

Cleanup    : openssl-devel-1.0.1e-30.el6_6.5.x86_64                                   3/4

Cleanup    : openssl-1.0.1e-30.el6_6.5.x86_64                                         4/4

Verifying  : openssl-1.0.1e-30.el6_6.7.x86_64                                         1/4

Verifying  : openssl-devel-1.0.1e-30.el6_6.7.x86_64                                   2/4

Verifying  : openssl-1.0.1e-30.el6_6.5.x86_64                                         3/4

Verifying  : openssl-devel-1.0.1e-30.el6_6.5.x86_64                                   4/4

Updated:

openssl.x86_64 0:1.0.1e-30.el6_6.7

Dependency Updated:

openssl-devel.x86_64 0:1.0.1e-30.el6_6.7

Complete!

Debian/Ubuntu Linux

Type the following apt-get commands to patch openssl as root user to patch openssl:

sudo apt-get update

sudo apt-get upgrade

Sample outputs:

Fig.04: OpenSSL patched on a Ubuntu Linux

Do I need to reboot my server/laptop/computer powered by Linux?

Short answer – yes, you need to reboot your computer/server to make all the necessary changes. Sysadmin should plan on updating as soon as possible or use maintenance reboot window:

sudo reboot

Long answer – It depends. You can avoid reboot by restarting required services. Fist, find all services that depend on the OpenSSL libraries, and restart them one-by-one using the service command:

Debian/Ubuntu find out if service needed reboot ##

checkrestart -v

Generic method ##

lsof | grep libssl | awk  {print $1}  | sort | uniq

Sample outputs:

hhvm

mysqld

nginx

php5-fpm

Restart the above services one-by-one, run:

sudo service restart hhvm restart

sudo service restart mysqld restart

sudo service restart nginx restart

sudo service restart php5-fpm restart

References

OpenSSL Security Advisory [19 Mar 2015]

DSA-3197-1 openssl — security update

USN-2537-1: OpenSSL vulnerabilities

OpenSSL Updates of 19 March 2015

LibreSSL addresses a number of security issues in coordination with the OpenSSL project released on 19 March 2015

n 19th March 2015, multiple high and moderate severity level vulnerabilities released in OpenSSL, a Secure Sockets Layer toolkit used in a Linux and Unix-like systems. How can I fix these vulnerabilities on a CentOS/RHEL/Ubuntu and Debian Linux based server for OpenSSL versions 1.0.2a, 1.0.1m, 1.0.0r, and 0.9.8zf.? How do I verify that my Linux server has been fixed against the OpenSSL vulnerability?

A serious security problem has been found and patched in the OpenSSL Library. Multiple vulnerabilities have been discovered in OpenSSL on 19/March/2015. The Common Vulnerabilities and exposures project identifies the following issues:

OpenSSL 1.0.2 ClientHello sigalgs DoS (CVE-2015-0291) – Severity: High

Reclassified: RSA silently downgrades to EXPORT_RSA [Client] (CVE-2015-0204) – Severity: High

Multiblock corrupted pointer (CVE-2015-0290) – Severity: Moderate

Segmentation fault in DTLSv1_listen (CVE-2015-0207) – Severity: Moderate

Segmentation fault in ASN1_TYPE_cmp (CVE-2015-0286) – Severity: Moderate

Segmentation fault for invalid PSS parameters (CVE-2015-0208) – Severity: Moderate

ASN.1 structure reuse memory corruption (CVE-2015-0287) – Severity: Moderate

PKCS7 NULL pointer dereferences (CVE-2015-0289) – Severity: Moderate

Base64 decode (CVE-2015-0292) – Severity: Moderate

DoS via reachable assert in SSLv2 servers (CVE-2015-0293) – Severity: Moderate

Empty CKE with client auth and DHE (CVE-2015-1787) – Severity: Moderate

Handshake with unseeded PRNG (CVE-2015-0285) – Severity: Low

Use After Free following d2i_ECPrivatekey error (CVE-2015-0209) Severity: Low

X509_to_X509_REQ NULL pointer deref (CVE-2015-0288) Severity: Low

How bad will this actually be?

It is not bad as the heartbleed openssl bug disclosed in April 2014 in the OpenSSL cryptography library. But, new bug can cause “Denial of Service” and crash your services. It is good security practice, to quickly apply the patched version on your system and restart the affected services.

How to find openssl version on a Linux?

The syntax is as follows:

Find openssl version on a CentOS/RHEL/SL/Fedora Linux

openssl version

or ##

sudo yum list installed openssl

Sample outputs:

Fig.01: How to RHEL/CentOS/Fedora Linux Find OpenSSL Version Command

Find openssl version on a Debian/Ubuntu Linux

openssl version

or ##

sudo dpkg -l | egrep   ^ii.*openssl

Sample outputs:

Fig.02: How to Debian/Ubuntu Linux Find OpenSSL Version Command

A list of affected Linux distros

I recommend that you upgrade your openssl packages ASAP to avoid any security issues on both client and server systems powered by Linux based distro.

RHEL version 6.x

RHEL version 7.x

CentoS Linux version 6.x

CentoS Linux version 7.x

Debian Linux stable (wheezy) 7.x

Ubuntu Linux 14.10

Ubuntu Linux 14.04 LTS

Ubuntu Linux 12.04 LTS

Ubuntu Linux 10.04 LTS

How to patch on a Linux?

Type the following commands as per your distro version/type:

how do I find out my distro version? ##

lsb_release -a

or use ##

cat /etc/*-release

Sample outputs:

Gif 01: HowTo: Find Out My Linux Distribution Name and Version

CentOS/RHEL/Fedora Linux

Type the following yum command to patch openssl as root user to patch openssl:

sudo yum clean all

To install the updates, use the yum command as follows:

sudo yum update

To only update the OpenSSL package and its dependencies, use the following yum command:

sudo yum update openssl

Sample outputs:

Loaded plugins: auto-update-debuginfo, protectbase, rhnplugin, security

This system is receiving updates from RHN Classic or RHN Satellite.

Setting up Update Process

epel-debuginfo/metalink                                  |  13 kB     00:00

rhel-x86_64-server-6                                     | 1.5 kB     00:00

rhel-x86_64-server-6/primary                             |  21 MB     00:05

rhel-x86_64-server-6                                                14680/14680

rhel-x86_64-server-6-debuginfo                           | 1.3 kB     00:00

rhel-x86_64-server-6-debuginfo/primary                   | 1.1 MB     00:00

rhel-x86_64-server-6-debuginfo                                        5939/5939

rhel-x86_64-server-optional-6                            | 1.5 kB     00:00

rhel-x86_64-server-optional-6/primary                    | 2.0 MB     00:00

rhel-x86_64-server-optional-6                                         8239/8239

rhel-x86_64-server-optional-6-debuginfo                  | 1.3 kB     00:00

rhel-x86_64-server-optional-6-debuginfo/primary          | 681 kB     00:00

rhel-x86_64-server-optional-6-debuginfo                               3571/3571

0 packages excluded due to repository protections

Resolving Dependencies

–> Running transaction check

—> Package openssl.x86_64 0:1.0.1e-30.el6_6.5 will be updated

–> Processing Dependency: openssl = 1.0.1e-30.el6_6.5 for package: openssl-devel-1.0.1e-30.el6_6.5.x86_64

—> Package openssl.x86_64 0:1.0.1e-30.el6_6.7 will be an update

–> Running transaction check

—> Package openssl-devel.x86_64 0:1.0.1e-30.el6_6.5 will be updated

—> Package openssl-devel.x86_64 0:1.0.1e-30.el6_6.7 will be an update

–> Finished Dependency Resolution

Dependencies Resolved

================================================================================

Package          Arch      Version               Repository               Size

================================================================================

Updating:

openssl          x86_64    1.0.1e-30.el6_6.7     rhel-x86_64-server-6    1.5 M

Updating for dependencies:

openssl-devel    x86_64    1.0.1e-30.el6_6.7     rhel-x86_64-server-6    1.2 M

Transaction Summary

================================================================================

Upgrade       2 Package(s)

Total download size: 2.7 M

Is this ok [y/N]: n

Exiting on user Command

[root@txvip1 ~]#

[root@txvip1 ~]# yum update openssl

Loaded plugins: auto-update-debuginfo, protectbase, rhnplugin, security

This system is receiving updates from RHN Classic or RHN Satellite.

Setting up Update Process

0 packages excluded due to repository protections

Resolving Dependencies

–> Running transaction check

—> Package openssl.x86_64 0:1.0.1e-30.el6_6.5 will be updated

–> Processing Dependency: openssl = 1.0.1e-30.el6_6.5 for package: openssl-devel-1.0.1e-30.el6_6.5.x86_64

—> Package openssl.x86_64 0:1.0.1e-30.el6_6.7 will be an update

–> Running transaction check

—> Package openssl-devel.x86_64 0:1.0.1e-30.el6_6.5 will be updated

—> Package openssl-devel.x86_64 0:1.0.1e-30.el6_6.7 will be an update

–> Finished Dependency Resolution

Dependencies Resolved

============================================================================================

Package             Arch         Version                  Repository                  Size

============================================================================================

Updating:

openssl             x86_64       1.0.1e-30.el6_6.7        rhel-x86_64-server-6       1.5 M

Updating for dependencies:

openssl-devel       x86_64       1.0.1e-30.el6_6.7        rhel-x86_64-server-6       1.2 M

Transaction Summary

============================================================================================

Upgrade       2 Package(s)

Total download size: 2.7 M

Is this ok [y/N]: y

Downloading Packages:

(1/2): openssl-1.0.1e-30.el6_6.7.x86_64.rpm                          | 1.5 MB     00:00

(2/2): openssl-devel-1.0.1e-30.el6_6.7.x86_64.rpm                    | 1.2 MB     00:00

Total                                                       6.4 MB/s | 2.7 MB     00:00

Running rpm_check_debug

Running Transaction Test

Transaction Test Succeeded

Running Transaction

Updating   : openssl-1.0.1e-30.el6_6.7.x86_64                                         1/4

Updating   : openssl-devel-1.0.1e-30.el6_6.7.x86_64                                   2/4

Cleanup    : openssl-devel-1.0.1e-30.el6_6.5.x86_64                                   3/4

Cleanup    : openssl-1.0.1e-30.el6_6.5.x86_64                                         4/4

Verifying  : openssl-1.0.1e-30.el6_6.7.x86_64                                         1/4

Verifying  : openssl-devel-1.0.1e-30.el6_6.7.x86_64                                   2/4

Verifying  : openssl-1.0.1e-30.el6_6.5.x86_64                                         3/4

Verifying  : openssl-devel-1.0.1e-30.el6_6.5.x86_64                                   4/4

Updated:

openssl.x86_64 0:1.0.1e-30.el6_6.7

Dependency Updated:

openssl-devel.x86_64 0:1.0.1e-30.el6_6.7

Complete!

Debian/Ubuntu Linux

Type the following apt-get commands to patch openssl as root user to patch openssl:

sudo apt-get update

sudo apt-get upgrade

Sample outputs:

Fig.04: OpenSSL patched on a Ubuntu Linux

Do I need to reboot my server/laptop/computer powered by Linux?

Short answer – yes, you need to reboot your computer/server to make all the necessary changes. Sysadmin should plan on updating as soon as possible or use maintenance reboot window:

sudo reboot

Long answer – It depends. You can avoid reboot by restarting required services. Fist, find all services that depend on the OpenSSL libraries, and restart them one-by-one using the service command:

Debian/Ubuntu find out if service needed reboot ##

checkrestart -v

Generic method ##

lsof | grep libssl | awk  {print $1}  | sort | uniq

Sample outputs:

hhvm

mysqld

nginx

php5-fpm

Restart the above services one-by-one, run:

sudo service restart hhvm restart

sudo service restart mysqld restart

sudo service restart nginx restart

sudo service restart php5-fpm restart

References

OpenSSL Security Advisory [19 Mar 2015]

DSA-3197-1 openssl — security update

USN-2537-1: OpenSSL vulnerabilities

OpenSSL Updates of 19 March 2015

LibreSSL addresses a number of security issues in coordination with the OpenSSL project released on 19 March 2015