Recently requested by the company, the need for remote transmission and backup of file data, wrote an article on the SSH, SCP and rsync application configuration of the whole process, may be too wordy, but mainly to want to do not miss each process in the case of this elaboration, I hope you can understand. Of course, there are many similar articles, this article only in the name of the individual to write, do not like to spray! If there is anything wrong in the article, please ask the great God to give you a lot of advice! Thank you very much!
Application of SSH in file sharing
This SSH is not only a remote login service, in fact! It includes several components: SSH (telnet), sftp (File Share "ftp-like"), SCP (File share "similar to CP copy"). So when you hear SSH, do not think that this software package can only be used when the remote login, nothing else to do, in fact, is not the case. I hope you understand!
First we first look at SSH remote login things, we normally use the Client remote login management tools (such as: SECURECRT, Xshell, etc... ) to do the control of login management, however,
What should we do if we want to log on to another Linux server from one Linux server?
We can use SSH command "ssh telnet: SSH username @ remote Host IP address" to log in, but when we log in, we should pay attention to the following rules:
A. Cannot log on with a blank password
B. You cannot log in as root (depending on the CentOS version, most of the CentOS version is now the default is to allow the root user to log in, this is only as an exception, for security reasons, generally we recommend that you do not use the root user login, Therefore, it is recommended to build a root user to authorize ordinary users to perform daily operations.
Here's how SSH commands are used:
SSH telnet: SSH user name @ remote Host IP address
2 forced to use the second-generation SSH protocol (two versions of SSH development, it is recommended to use SSH2, because it is more secure, I here for demonstration, some may directly default login, in this statement, we now use the SSH version is this openssh it, It supports both SSH1 and SSH2)
-P Port number
ssh-2 [email protected]
I'm going to have two CentOS servers on my side, with the following information:
Machine One: 192.168.1.17 already exists ordinary User: formal
Machine Two: 192.168.1.18 already exists ordinary User: formal
For example I telnet here from 17 servers to 18 servers:
--Log on to 17 server, switch to normal user, 1:
--use SSH command to telnet to 18 server from 17 server, prompt you to continue the connection login, enter Yes directly, 2:
SSH [email protected]
Since we did not set the password for the formal user, we directly enter. You will find that the request was rejected. This is because the CentOS system by default cannot log on with a blank password when logging in. As a result, we are here to set a password for two of the normal users of the server at the same time, for later use, 3:
Set the password (here to special instructions, use the normal user to set the password directly, you can directly use the passwd command to set, but the password must not be too short and simple, to contain special characters, otherwise you will not be set to succeed. If you use the root user to set a password, you can use the passwd user name, set the password with the root user can use a simple password. To facilitate testing, I use the root user to set the password directly here.), here the password is: formal
Delete password (root user Delete method: passwd-d formal; Normal User Delete method: passwd-d here to explain, with the root user created for the normal user password can only be deleted by the root user)
--Well, since the user password we have set up, then continue to login to try, enter the password, login success. 4:
SSH [email protected]
--Next, let's introduce the common configuration of SSH. Here is mainly to introduce you how to prohibit the root user login, and how to change the port number of SSH.
--Using the root user, edit the 18 server's/etc/ssh/sshd_config file, we can see Permitrootlogin yes this sentence is commented out, By default, it is possible to log on by using the root user, so this remark and no comment can be logged in with the root user. 5, 5-1:
SSH [email protected]
If we want to prevent root user login, as long as the permitrootlogin Yes in the sentence to no means that the root user login can not be allowed, after the change we restart the SSH service, and then the 17 server using the root user login test, You can find that 18 servers prohibit us from using the root user to telnet to the server, 6, 6-1:
Service sshd Restart
SSH [email protected]
--Next we'll look at how to change the port number for SSH login.
Normally, when we telnet to another server using the SSH command, we use the default 22 port login, if we want to change the port number of the login, we can change the Port 22 property in the/etc/ssh/sshd_config file, and replace 22 with the port number you want to modify the login. For example, I will change the 18 server login port to 10022, restart the SSH service login, 17 server login 18 Server, this time the login command requires us to add-p to specify the login port number. Test results, 7-1,7-2,7-3:
ssh-p10022 [email protected]
about SSH Telnet, say these , for SFTP generally use less, here no longer say, have the interest of children's shoes themselves can find degrees Niang check related information.
Next, let's introduce the application of SCP. Talking about the application of SCP, is actually very simple, normal we in the process of application, we can very convenient to copy the native files to the remote host, of course, you can also copy the files on the remote host to the machine. The use of SCP is as follows:
Copy native files to remote host
SCP local file user name @ remote host IP address: remote host destination directory
scp-r local directory user name @ remote host IP address: remote host destination directory
remote host file copied to native
SCP username @ remote Host IP address: remote host file local directory
Scp-r user name @ remote host IP address: Remote host directory local directory
-P (lowercase) keep the original file properties ( Backing up a file to another place is equivalent to creating a directory, such as the time will change, if we want to let the related attribute inconvenience add this property can be)
-r copy directory
-p (uppercase) specify Port
Note: case is to distinguish between property and port conflicts
Reminder: When we use the SCP command again, we must have a valid user identity, and this user must be the remote host target directory has write permission, for example: You can not use Xushouwei user copy files to the/root directory. So generally speaking, it is written to the user has write permission to the directory. You need to pay attention here.
Scp/home/formal/xushouwei.properties [email protected]:/root/using the command copy will prompt permission denied ( Permission denied), 8:
--Copy files from 17 server to 18 server (upload), 9:
scp/home/formal/xushouwei.properties [Email Protected]:/home/formal
Copy before and after 18 server changes, 9-1:
--Copy directory from 17 server to 18 server (upload), 10:
Copy before and after 18 server changes, 10-1:
--Copy files from 18 server to 17 server (download), 11:
SCP [Email protected]:/home/formal/xushouwei.properties/home/formal/
--Copy directories from 18 servers to 17 servers (download), 12:
scp-r [Email protected]:/home/formal/com//home/formal/
So this SCP copy, which is very simple to use, is one of the recommended ways for us to use, and it is more secure than other transmission methods to transmit data in the process of file transfer. It is also more convenient to use. So we can easily periodically from the remote host to the local and from the local to the remote host for backup and copy, but here is a problem, is the execution of the command when the password is executed, the implementation of the password, there is no way to achieve automated backup and copy tasks, We will then introduce the establishment of trusted hosts to enable automated backups.
--symmetric key Encryption (example: "Lock" used in our home) 13:
Features: Encryption and decryption using the unified secret key
Advantages: Fast Speed
Cons: The secret key itself needs to be exchanged
--Asymmetric secret key encryption (public key encryption) 14:
Features: Use time to generate two keys, one public storage, for the public key; a private hold, as the private key; The data encrypted with one of the keys can only be decrypted with the other secret key.
Encrypt files with public key encryption, private key decryption
Digital signature with private key encryption, public key decryption
Advantages: Good security
Cons: Slow speed
Our trusted host is the use of asymmetric key encryption principle to achieve, currently we from one host login to another host important input password, this is too much trouble, can not think of a way to tell the other host, as long as I this user login you will establish a trust relationship, do not need a password, Then this should have a method, a host bar public key generation, to another host, another host to the public key as a certified public key, this time using SSH login without the need for password, look at the principle 15 diagram:
Since the principle has been said, we are in the actual operation ...
I define here: Host one IP is 192.168.1.17, the user is non-root user formal, host two IP is 192.168.1.18, the user is a non-root user formal.
--Generate a key pair on a 17 server using the formal user:
At this point you will be prompted to suggest a public key and a private key and then tell you where the secret key is saved, the default location is:/home/formal/.ssh/ Directory. Immediately after the carriage return will prompt you authentication, enter the password authentication, this setting I direct enter here, then will prompt you to enter the password authentication, continues the carriage return. The whole process 16, where your public key had been saved in/home/formal/.ssh/id_rsa.pub. That's what you just said. The key location you generated using the command:
--Immediately after the car we copy the public key just generated to the/home/formal directory on host two. Enter the following command and enter the password, 17:
scp/home/formal/.ssh/id_rsa.pub [Email protected]:/home/formal/
You see now we do copy or login or need a password, our purpose is to let him do not need the password, then we need to operate the host two.
--Login host two and switch to formal user, 18: We can see there is a Id_rsa in the/home/formal directory
We can see that there is a id_rsa.pub file in the/home/formal directory, yes, this is the secret key that we have just used to copy the host life. All we have to do is to process this public key file and generate a trust key file. So we need to do the following steps on the host two:
It is necessary to remind that each user's SSH information is stored in the. SSH directory of their own host directory, but this directory is not automatically created by each system (no need to create manually, using the command: mkdir. SSH), But under the centos6.7 system this directory is hidden by default, and we can use Ls-la to view the contents of the host directory, as shown in 19:
--Regenerate the Id_rsa.pub file output from the current directory to the. SSH directory, create a new authentication file called: Authorized_key (fixed), generate and view, 20:
Cat Id_rsa.pub >> Ssh/authorized_keys
Then the current user's host directory under the. SSH Directory we created this authentication file establishes a trust relationship. In fact, this principle is very simple, just like the digital signature of the asymmetric key we just talked about, in other words you want to let others know that you are logged in, to establish a trust relationship with you, how to establish a trust relationship? First you have to give your public key to someone else, they use the public key to verify that you are logged in, you log in to let you log in, you establish a trust to establish a digital signature. This is the end of the normal process in many Linux versions. But in the new Linux is very strict permissions requirements, it requires in your user host directory under the. SSH directory file must be 700, that is, only this ordinary user has permissions, other users do not have permissions and require this permission to control the file permissions must be 600, That is, we are using the process only this formal user has read and write permissions. Here to remind you that this permission must be changed, because in the new Linux version of the permissions are very strict requirements. So we need to perform the following command, 21:
--At this point, the whole process of building our trust mainframe has been changed. Now let's test it right.
--From the host one telnet to the remote host two (this process is not prompting you to enter the password), 22:
SSH [email protected]
--from the host to a copy file to the remote host two (this process is not prompted to enter the password), 23:
SCP xushouwei.properties [Email protected]:/home/formal/
Note: The entire process requires special attention to the authentication principle of the trust relationship the user (a user establishes a trust host relationship), here you need to pay special attention to "full backup".
At this point, does anyone ask if there is an incremental backup? Because a lot of times, we do a full backup when the backup time may be relatively long, the backup time and the system time and resources are not ideal, then we choose the incremental backup is relatively fast, directly to a modified file to do an update. I recommend that you use the other tool "rsync", if you want to remotely synchronize the use of the tool, the following I have a brief introduction to the features of the tool:
A. Easy incremental backup Implementation
B. Can be mirrored to save the entire directory tree and file system
C. maintain file permissions, time, soft and hard links, etc.
D. File transfer efficiency
E. SSH encrypted channel can be used
Perhaps, many people will feel that the time to see some of the rsync data is particularly complex, in fact, we use the most commonly used methods on the line, Not to imagine how complicated it is, I'm going to use it most frequently for everyone to go through. Rsync this service by default in the Linux system is the use of xinetd (about xinetd knowledge please ask the mother) to carry out the hosting, and in all Linux is installed by default, so we will start the service first.
--View the rsync file location:
--Before using the first to determine whether rsync this software has installed, under normal circumstances all Linux default is installed, if not installed, download and install it Yourself (
Download: wget http://pkgs.repoforge.org/rsync/rsync-3.1.1-1.el6.rfx.x86_64.rpm Installation: Rpm-ivh rsync-3.1.1-1.el6.rfx.x86_64. RPM or install with Yum: Yum install-y rsync xinetd), 25:
--Use the root user to modify the/etc/xinetd.d/rsync configuration file, set the Disable property to No, restart the service xinetd restart start the rsync service. 26-1, 26-2:
Service xinetd Restart
At this point, the configuration of rsync to this step is possible. So how to use rsync next?
Case scenario: Do it two o'clock in the morning every day backup backs up the COM directory under the host directory (/home/formal/) directory on 18 (host two) to the host directory (/home/formal/) directory on 17 (host one). 27:
To formal a user with a non-root user:
0 2 * * */usr/bin/rsync-arhz--progress--delete [email protected]:/home/formal/com/home/formal
--Of course, we can do the manual backup directly for the convenience of operation, before we take a look at all the directory files in the host directory. 28:
--Use the following command to manually back up the file operation, 29:
--Look at all the directory files in the host directory again, when the host directory is more than a COM directory. 30:
Well, so far, we've learned to use the Rsync tool to make incremental backups of files. Let's analyze the backup. 31:
So far, the application of rsync is here ...
Installation and application of SSH, SCP and rsync under CentOS