Set ssh password-less key login in CentOS

If we manage enough servers, it is not difficult to enter the password every time. Here we have a proxy method ssh-agent, the ssh-agent is actually a key manager. It can also be understood as a butler. we hand over the key to the butler to keep it. Every time we open the door, the butler will help us open the door and enter the password, this is not very convenient.

Do you still remember the previous ssh key logon scenario:

Here is the password used to generate the key, but if we hand over the key to the butler for management and give the Butler a password, we will ask the butler to help us open the door every time we enter the door:

This is swollen. We can't establish a connection with the butler. We need to start the ssh-agent before we can add it. The butler has not yet started yet. How can we keep the key for him, how can I ask him to open the door and lose his password:

Of course, this proxy is not permanent. When we log out and log in again, this proxy disappears and we have to reset the proxy, windows is often used. We know that you can set boot items. If you are smart enough, you also know what to do here.

We can also use secureCRT to generate a key, send the public key to a user on the server, and then use the key to log on. This method can be found on the Internet in many tutorials without much explanation. Here I encountered a problem. I think the server can also generate a pair of private keys in the key and use secureCRT to specify the private key for key login, I don't know if this idea is correct.

Key logon is secure and convenient. So what is the process of key logon, how do we implement matching between our private key and the public key on the server? At first, my idea was that the server used my public key to encrypt a message and I decrypted it through the private key, then it is encrypted and sent to the server using the public key of the server. The server receives the decryption with its private key. If the message is sent by the server, the matching is successful.

For detailed ssh logon, visit http://blog.csdn.net/gsnumen/article/details/7293266.

The ssh logon process is divided into five phases:

1. Version Number negotiation stage

2. Key and algorithm negotiation stage

3. Authentication phase

4. Session Request stage

5. Session interaction stage

1. Version Number negotiation stage

The server opens port 22 and waits for the customer to connect.

The client initiates a TCP connection to the server. After the connection is established, the server sends the first packet to the client, including the version flag string, in the format of "Protocol version number" and "Protocol version number ".

After the client receives the message, it parses the Protocol version number. If the Protocol version number of the server is lower than its own, and the client can support the earlier version of the server, it uses the Protocol Number of the server, otherwise, use your protocol version.

The client replies to a message from the server, which contains the Protocol version number determined by the client.

The server compares the version number sent by the client to determine whether it can interact with the client.

If the negotiation is successful, the key-algorithm negotiation phase is entered. Otherwise, the server disconnects the TCP connection.

2. Key and algorithm negotiation stage

The server and client respectively send algorithm negotiation packets to each other. The messages contain their own public key algorithm list, encryption algorithm list, message verification code algorithm list, and compression algorithm list.

The server and client obtain the final algorithm based on the algorithms supported by the other party and themselves.

The server and client generate the session key and session ID using the DH exchange algorithm and host key-to-Peer parameters.

Public Key of the c-Client

C-key client key

S public server Public Key

S secret server key

After the version number negotiation stage is complete:

The server sends s public to the client.

The session ID generated by the server, which is set to id and sent to the client.

The client generates a session key, sets it to key, and calculates the res = id difference or key.

The client encrypts res with s public and sends the result to the server.

The server uses the s password for decryption to obtain the res.

The server calculates the res variance or id to obtain the key.

Now the server and client know the session key and session ID, and later data transmission uses the session key for encryption and decryption.

3. Authentication phase

Account and password-based verification methods:

The client uses the session key encrypted account, authentication method, and password generated during key and algorithm negotiation to send the result to the server.

The server decrypts the message using the obtained session key to obtain the account and password.

The server determines the account and password. If the password fails, the server sends an authentication failure message to the client, which contains a list of methods for re-authentication.

The client selects a method from the authentication method list for re-authentication.

This process is repeated until the authentication succeeds or the maximum number of authentications has been reached. The server closes the TCP connection.

Public Key and private key-based verification methods:

The ssh-keygen program is used to generate the Public Key id_dsa.pub and the private key id_dsa. Generally, id_dsa.pub is generated on the client and then sent to the server in some way.

The server is placed under the. ssh directory of the account to be remotely logged on.

The client uses the session key encrypted account, authentication method, and id_dsa.pub generated during key and algorithm negotiation to send the result to the server.

The server uses the session key to decrypt the message and obtain the account and id_dsa.pub. The server is in the directory of this account. find the corresponding public key in the ssh directory. If no public key is found, send the failed message to the client. If yes, compare the public key sent by the client with the public key found. If the content is the same, the server generates a random string, referred to as "Question", encrypts the question with the found public key, and then encrypts the question again with the session key.

The server sends the double encrypted data to the client.

The client uses the session key to decrypt the message, and then uses id_dsa to decrypt the data again to obtain a question.

The client uses the session key to encrypt the question and send it to the server.

The server uses the session key to decrypt the message, obtain the question, and determine whether the question is generated by itself. If the question is different, the server sends the failed message to the client. If the question is the same, the server passes the authentication.