As you may have thought, since SSH can use the SCP for network replication, can I place the SCP directives in the crontab service, allowing our system to replicate and backup the network directly under the background through the SCP? Sorry, the answer is: "This action is not allowed under preset conditions." Why, then? Because of the preset situation, you have to enter a password to interact with the SCP through remote logins. But crontab will not let you have a terminal interface to enter the password, so the program will always be stuck and can not be implemented in crontab success OH. What do you do? Are we going to give up this handy web-copying tool? Of course not. We can handle it through a key authentication system.
Since SSH can use a key system to compare data and provide encryption of user data, it is not possible to use this key to provide the user with access to the host without having to enter a password. Oh. Good idea. We can copy the client-generated key to the server, so that when the client logged in to the server, the two were already on the key when the SSH was going to be online, so you could immediately enter the data transfer interface without having to enter the secret Yards. In the implementation of the steps can be: The client set up two key: think, in the key system, is the public key more important or private key is more important. Of course, the private key is more important. So the private key is the key to decryption. So, of course, these two keys have to be built on the client that is online. The command used is ssh-keygen this order;
The client places a good private key file: The private key placed on the client's home directory, that is $HOME/.ssh/, and must pay attention to permissions Oh.
Place the public key on the server side of the correct directory and filename: Finally, put that "key" in any User's home directory that you want to use to log on to the server. ssh/inside the certification file can complete the entire program.
Said it seems very difficult to look, in fact, the steps are really very simple, we are in order to do the homework well. Assuming the following, the steps to proceed are as follows: The Server part is Www.centos.vbird this 192.168.100.254 host, the account that wants to use is dmtsai; the Client part is Clientlinux.centos.vbir D This 192.168.100.10 Vbirdtsai account, which is used to log into the 192.168.100.254 Dmtsai account.
Figure 11.2-10, the basic process of making SSH account without the need for a password
1. The client establishes two keys:
The establishment of the method is very simple, in the Clientlinux.centos.vbird this host to Vbirdtsai as the identity of the two key can be established. However, it should be noted that we have a variety of cryptographic algorithms, and if no special algorithm is specified, the default is handled by the RSA algorithm:
Please note above oh, my identity is vbirdtsai, so when I perform ssh-keygen, it will be in my home directory. ssh/This directory produces the two keys needed, namely the private key (ID_RSA) and the public key (Id_rsa.pub). The ~/.ssh/directory must be 700 in the right order. The other one to pay special attention to is that Id_rsa file permission. He must-rw-------and belong to Vbirdtsai himself. Otherwise, in the process of future key alignment, it may be judged as dangerous and can not be successful in the public key into the file of the mechanism to achieve online oh. In fact, after the establishment of the private key preset permissions and filename placement is correct, you only have to check the problem can be.
2. Upload the public key file data to the server:
Because we want to log in to the Www.centos.vbird as Dmtsai, we have to upload the public key (ID_RSA.PUB) established by the previous step to the Dmtsai user on the server. Then how to upload it. The easiest way of course is to use the SCP.
3. Put the public key on the server side of the correct directory and file name:
Remember what Sshd_config said about the Authorizedkeysfile this set value. The set value is the name of the file where the public key data should be placed. Therefore, we must go to server-side Dmtsai This user identity, will just upload the id_rsa.pub data appended to authorized_keys this file. It's kind of like this:
That's how the key system is handled. When you log in to the Dmtsai user of Www.centos.vbird from Clientlinux.centos.vbird's Vbirdtsai, you don't need any password. For example, you can test this to see:
Example: After the success of the above case practice, please copy the system/etc/hosts* file to Www.centos.vbird's Dmtsai user's home directory in the Clientlinux Vbirdtsai identity. For:
|
It's a very simple step. This allows you to use SSH-related client directives without the need for a password procedure. In any case, you should remember in the steps of establishing a key system that the Client must create the two keys of public & private, and that the private need to be placed in the ~/.ssh/; the Server must have public key and be placed in the user ~/.ssh/authorized_keys in the home directory, while the directory permissions (. ssh/) must be 700 and file permissions must be 644, and the file owner and the group must match the account.
In the future, when you want to log in to another host, just copy your public key (the Id_rsa.pub file) to another host, and add it to the ~/.ssh/authorized_keys file for an account. Ha ha. Success.