Linux Host Trust

Source: Internet
Author: User
Tags using git

Linux Configure SSH Trust

What do you mean by Linux host Trust:

Linux Host Trust, is the host of mutual trust, what is the trust, like people and people, do not need to use money and so on (in addition to your own other things) to obtain the other side of the trust, we trust each other, do not need additional credentials. Like you, your father, your mother, your sister, do not need money to maintain the trust between you. also, between the Linux hosts, we log in from one host to another, often need to verify you, you need to enter the user password to allow you to log in. In this way, switching back and forth between multiple machines will enter the password frequently, very troublesome, to see that the root of everything comes from mutual distrust. Do you want to log in directly without entering your password? The answer is yes, but the condition is that the host trusts each other.

so SSH Trust is born. After we have configured the public key authentication between the host values, that is, after obtaining the trust, we do not have to enter the password (of course, SSH uses the RSA algorithm to help you complete the verification process).

The basic idea of public key authentication:

The encryption and decryption of information takes different keys, which are called private keys and PublicKey, where public key is stored on the server that you want to log on to, and Privatekey is held by a specific client. When the client makes a request to establish a secure connection to the server, first sends its own public key, if the public key is allowed by the server, the server sends a public key encrypted random data to the client, this data only through the private Key decryption, the client sends the decrypted information back to the server, the server verifies that the client is trustworthy, and thus establishes a secure information channel. In this way, the client does not need to send its own identity flag "private key" to achieve the purpose of verification, and private key can not be inferred from the public key backwards. This avoids the potential for password leaks caused by network eavesdropping. Clients need to be careful to save their own private key, so as not to be stolen by others, once such a thing happens, it is necessary for each server to replace the trusted PublicKey list.

users who have used GitHub will know that when using git to log in to remote repository GitHub, there will be a public key authentication (when using Git for the first time, of course), and for the first time git will require you to generate an RSA key pairs on the client, A public-key is stored in id_rsa.pub, a private-key is stored in Id_rsa, and uploading your public key public-key to GitHub is done so that you can gain the trust of GitHub, That is, github trusts you, and next time you log in, GitHub will use your uploaded public key to verify your identity, so you don't have to enter a password. Of course this process is just a one-way trust, that is, GitHub now trusts you, but you do not have to build the trust of GitHub, need to build, in fact, it is not necessary, because GitHub is not unsolicited request to you, in most cases, you need to proactively send requests to GitHub.

Know the one-way trust, then mutual trust is simple, that is, the public key between the host to inform each other, so as to trust each other, you trust me, I trust you. So, here are the steps to build trust:

The steps to configure SSH Trust are as follows:

1. first, on the machine to configure mutual trust, the generation of their own certified key files;

2. Next, all the key files are aggregated into a total certification file;

3. Distribute this certification document, which contains all trusted machine authentication keys , to each machine;

4. Verify mutual trust.

Create SSH trust with the same user test on the host named Node1,node2,node3 .

1. Create an RSA key and public key on each node

Login with test user

Mkdir~/.ssh

chmod700 ~/.ssh

Cd~/.ssh

SSH-KEYGEN-T RSA

2. consolidating public key files

Execute the following command on the Node1

Sshnode1 Cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys

Sshnode2 Cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys

Sshnode3 Cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys

chmod600 ~/.ssh/authorized_keys

3. Distributing the Consolidated public key file

Execute the following command on the Node1

Scp~/.ssh/authorized_keys node2:~/.ssh/

Scp~/.ssh/authorized_keys node3:~/.ssh/

4. test SSH Trust

run the following command on each node, if you do not need to enter a password to display the current date of the system, it means that SSH Trust has been configured successfully.

Sshnode1 Date

Sshnode2 Date

Sshnode3 Date

This is my experiment.

[email protected]. ssh]$ ssh-keygen-t RSA

Generating public/private RSA key pair.

Enter file in which to save the key (/HOME/OCDC/.SSH/ID_RSA):

/home/ocdc/.ssh/id_rsa already exists.

Overwrite (y/n)? Y

Enter passphrase (empty for no passphrase):

Enter same Passphrase again:

Your identification has been saved In/home/ocdc/.ssh/id_rsa.

Your public key has been saved in/home/ocdc/.ssh/id_rsa.pub.

The key fingerprint is:

B3:e7:19:4b:e1:59:0d:b5:4d:ba:04:89:81:9d:37:[email protected]

The key ' s Randomart image is:

+---[RSA 2048]----+

| Oe=oo. .|

| . + +o = |

| ...+ .|

| + . |

| S. . o |

| + +     |

| . *      |

| + +     |

| +      |

+-----------------+

Then repeat the above steps to generate the authentication file on each interface machine that requires mutual trust.

Back to interface Machine 1,

[email protected]. ssh]$ ssh10.31.100.21 cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys

[email protected] ' s password:

[email protected]. ssh]$ ssh10.31.100.22 cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys

[email protected] ' s password:

[email protected]. ssh]$ ssh10.31.100.23 cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys

[email protected] ' s password:

[email protected]. ssh]$ ssh10.31.100.24 cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys

[email protected] ' s password:

[email protected]. ssh]$ Catauthorized_keys

You can see that all the host's public keys are present in Authorized_keys. The next step is to distribute the consolidated certificate.

[email protected]. ssh]$ Scp~/.ssh/authorized_keys 10.31.100.21:~/.ssh/

[email protected] ' s password:

Authorized_keys 100% 3219 3.1kb/s 0 0:00

[email protected]. ssh]$ Scp~/.ssh/authorized_keys 10.31.100.22:~/.ssh/

[email protected] ' s password:

Authorized_keys 100% 3219 3.1kb/s 0 0:00

[email protected]. ssh]$ Scp~/.ssh/authorized_keys 10.31.100.23:~/.ssh/

[email protected] ' s password:

Authorized_keys 100% 3219 3.1kb/s 0 0:00

[email protected]. ssh]$ Scp~/.ssh/authorized_keys 10.31.100.24:~/.ssh/

[email protected] ' s password:

Authorized_keys 100% 3219 3.1kb/s 0 0:00

Task complete, verify success

[email protected]. ssh]$ ssh10.31.100.21 Date

Wed 20:39:39 CST 2015

[email protected]. ssh]$ ssh10.31.100.22 Date

Wed 20:39:45 CST 2015

[email protected]. ssh]$ ssh10.31.100.23 Date

Wed 20:39:51 CST 2015

[email protected]. ssh]$ ssh10.31.100.24 Date

Wed 20:39:55 CST 2015

Linux Host Trust

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.