Linux entry series 14 — SSH service and host remote management


Through the introduction of more than ten previous articles, I believe that I have started the basic method of Linux local management. The following articles will introduce the common service deployment in Linux and how to provide corresponding services for the external.

The third part of the series “Linux entry series 3 — Linux remote login tool” introduces several tools for Linux remote login management. This article will explain SSH protocol and corresponding service configuration in detail, so as to better remote management server.

Tip: before operation, please install or clone two Linux virtual machines according to the method of the previous series of articles, assuming the IP addresses are and respectively (need to be configured according to their own actual situation), which is used to demonstrate SSH login between Linux systems. If you forget how to prepare 2 virtual machines, please refer to section 3 of the previous article “Linux entry Series 1 – environment preparation and Linux Installation” or section 1.3.1 of “Linux entry series 13 – raid and LVM technology for disk management”.

1、 Sshd remote control service

1.1 SSH overview

SSH, named secure shell in full, is a protocol that can provide remote login in a secure way, and is the preferred way to remotely manage Linux system at present. Before SSH appeared, FTP and telnet were generally used for remote login, but they all transmitted account password and data information in the form of clear text in the network, so they are very insecure. This way is very vulnerable to the attack of middleman initiated by hackers, so as to tamper with the data or intercept the server account password.

Sshd service in Linux is a remote management service program developed based on SSH protocol, which can remotely manage Linux system by configuring sshd service.

Sshd provides two security verification methods:Password based authenticationandKey based authentication

Password based authentication uses account passwords to log in to the system. As we mentioned in “Linux entry Series 1 – environment preparation and Linux Installation” earlier, root users and manually specified test users will be created by default when installing the system. With these user account passwords, you can log in to the system.

Key based authentication, which we haven’t introduced so far, needs to produce the key pair locally, and then upload the public key in the key pair to the server, which is more secure than password authentication.

Below we mainly demonstrate the method of certificate based login. Before the demonstration, we first configure the sshd service,In rhel7, the sshd service program is installed and enabled by default

1.2 SSH service configuration

The configuration information of sshd service is saved in / etc / SSH / sshd_ In the config file, you can see that there are many contents in the file, but most of them are annotated. We can flexibly configure them according to our needs.

Common configuration parameters and functions are as follows:

parameter explain
Port Sshd service port, default is 22
ListenAddress Set the IP address that the sshd server listens to. The default is
Protocol Version number of SSH protocol
HostKey The value is / etc / SSH / SSH_ host_ Key, indicating the location where des private key is stored when SSH protocol version is 1; the value is / etc / SSH / SSH_ host_ rsa_ Key, indicating the location where RSA private key is stored when SSH protocol version is 2; the value is / etc / SSH / SSH_ host_ dsa_ Key, indicating the location where DSA private key is stored when SSH protocol version is 2
PermitRootLogin Set whether to allow root administrator to log in directly. The default is yes
StrictModes When the private key of the remote user is changed, the connection is directly rejected. The default value is yes
MaxAuthTries Maximum password attempts, default is 6
MaxSessions 10 Maximum number of terminals, default is 10
PasswordAuthentication Whether to allow password verification? Yes by default
PermitEmptyPasswords Allow null password login, default to no
1.2.1 save default configuration login

Since the sshd service has been installed and enabled by default in rhel7, and the parameters have default values, we can directly log in to other machines using SSH without any configuration.

Open the two prepared Linux hosts according to the method described at the beginning, and then perform the following operations:

[[email protected] ~]# hostname
[[email protected] ~]# ssh
The authenticity of host ' (' can't be established.
ECDSA key fingerprint is c1:b8:67:1f:1d:c0:cd:6b:37:90:42:b1:c6:5a:e8:cf.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '' (ECDSA) to the list of known hosts.
[email protected]'s password: 
Last login: Sun Jan  5 11:19:40 2020 from
[[email protected] ~]# hostname
[[email protected] ~]#

As you can see, without any configuration, you can log in to the heimatengyun host remotely from the origin host through the SSH command.

1.2.2 prohibit root remote login

Let’s change the configuration parameters of the host, heimatengyun, to prevent the root administrator from logging in remotely, and then observe the effect of logging in remotely.

  • First, configure the sshd service and modify the main configuration file / etc / SSH / sshd of the sshd service_ Config, find permitrootlogin yes to uncomment and change to No.
[[email protected] ~]# vim /etc/ssh/sshd_config 
Omit part of
PermitRootLogin no
.Omit part of

Save and exit. Restart the sshd service to view the results:

[[email protected] ~]# systemctl restart sshd
[[email protected] ~]# systemctl enable sshd
[[email protected] ~]#

Note that after modifying the sshd configuration, you must restart the sshd service for the configuration to take effect.

  • Second, we will go from the origin host SSH to the heimatengyun host again to see if we can log in
[[email protected] ~]# ssh
[email protected]'s password: 
Permission denied, please try again.
[email protected]'s password:

It can be seen that root can no longer log in to the system remotely, including all external SSH tools, which greatly reduces the chance of being brutally hacked into the password.

If you want to log in to this host, because we are currently demonstrating in the virtual machine, the only way is to log in to the virtual machine. In the production environment, the server is generally placed in the computer room, so you have to go to the computer room to connect the display, and then log in.

After the demonstration, we will first log in to the system through the virtual machine, modify the configuration back, and allow root to log in remotely

Note: the above demonstration is the SSH login between two Linux hosts, which directly uses the SSH command of the system. The SSH login between windows and Linux relies on various SSH tools. If the host prohibits root login, no remote SSH tool can log in. For the common SSH login tools, please refer to “Linux entry series 3 — Linux remote login tools” in the third part of the previous series.

1.3 log in with SSH certificate

Previous logins are in the form of account password. This section demonstrates the login through SSH certificate.

1.3.1 password free login between Linux hosts

In the previous demonstration, if you want to SSH Remote Login between two machines, you need to enter the password first. But sometimes it is necessary for the Linux host to be able to SSH free login without entering the password of the account. For example, when SSH on one machine executes some scripts on another machine, this process is often done through shell scripts without any human intervention. Therefore, in this case, it is necessary to set up mutual trust between machines, and the essence of password free login is certificate login.

Take the previous two machines for example. If you need to log in from (origin) to (heimatengyun), origin is the client host, and heimatengyun is the server remote host.

(1) Generate key pair on client host

Generated by SSH keygen command of the system

[[email protected] ~]# ssh-keygen 
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_ RSA): press enter or set key storage path
Enter passphrase (empty for no passphrase): press enter or set the password for the key
Enter same password again: press enter or set the password for the key
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/
The key fingerprint is:
bc:94:4e:e1:82:7c:4a:96:ad:a3:38:c5:d6:47:ac:94 [email protected]
The key's randomart image is:
+--[ RSA 2048]----+
|                 |
|                 |
|     o  .        |
|   .E+oo o       |
| . o*o+ S        |
|  +oo+.= .       |
| o  +.  o        |
|.. . .           |
|...              |
[[email protected] ~]# 
[[email protected] ~]# ls .ssh/
id_rsa  known_hosts

Note that in this process, press enter 3 times, and press enter directly without entering information to use the default value. You can see that the public key (ID) is generated in the. SSH folder under the root directory of the current user_ )And private key file (ID_ rsa)。

A key pair is generated.

(2) Public key file sent to remote host

Send the public key file just generated by the client to the remote host through SSH copy ID command

[[email protected] ~]# ssh-copy-id
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
[email protected]'s password: 
Number of key(s) added: 1
Now try logging into the machine, with:   "ssh ''"
and check to make sure that only the key(s) you wanted were added.
[[email protected] ~]#

After entering the password of the remote host, the public key file is successfully sent to the remote host.It is actually the ID produced in the first step_ The contents of the public key file are written to the remote host’s.ssh/authorized_ In the keys file, generate the known in your own. SSH directory at the same time_ Hosts file, which records the information of the remote host。 You can check these two files of the two hosts by yourself. In addition, because the nature of authorization operation is file operation, when SSH is not required, only the files under the. SSH directory need to be deleted.

After the above operation, you can log in to the host directly and remotely.

[[email protected] ~]# ssh
Last login: Sun Jan  5 11:36:52 2020 from
[[email protected] ~]#

You can see that you can log in to the remote service host directly without entering the root password. But at this time, the remote host heimatengyun can still log in remotely through the account password.

If you specified the certificate’s key in the first step, you need to enter the certificate’s password to log in when you log in. Note that the certificate password is not the user’s password

(3) Set the remote host to allow only key certificate login and deny password login mode

Enter the heimatengyun host and disable password login

[[email protected] ~]# vi /etc/ssh/sshd_config 
Omit part of
PasswordAuthentication no
Omit part of
[[email protected] ~]# systemctl restart sshd.service 
[[email protected] ~]#

Save to exit and restart the sshd service.

(4) Verify remote login

Remote login from origin to server host

[[email protected] ~]# ssh
Last login: Sun Jan  5 12:36:48 2020 from
[[email protected] ~]#

You can see that you can still log in successfully and normally through SSH certificate.

However, at this time, if you log in from windows through remote tools, such as xshell and SecureCRT, you cannot log in. This shows that even if root is allowed to log in, but it is not allowed to log in through account, root still cannot log in remotely. If root wants to log in, he has to log in to the virtual machine. In the formal environment, he has to log in to the computer room.

Note: during SSH password free login, you can log in to heimatengyun from origin password free through the above settings, but not vice versa. If you want to make it vice versa, you need to use the same method to produce a key pair on the heimatengyun host, and then transfer its public key to the origin host. In this way, the mutual SSH free login between hosts is realized.

1.3.2 certificate login between window host and Linux host

We can also generate key pairs under windows, so that we can log in to linxu server through certificate under windows. However, SSH keygen cannot generate key pairs under windows. You need to install the corresponding key generation tools to generate. There are many such tools, including SecureCRT, xshell, putty and so on.

The generation methods of each tool are slightly different, but due to space limitations, only SecureCRT is shown here as an example

(1) Using SecureCRT to generate key pair on Windows

Tools – generate public key


Click “next” in the pop-up Wizard


Keep the RSA algorithm selected by default and click “next”


Enter the certificate password or not. If you enter it, you need to specify the certificate and enter the password at the same time when you log in,Note that the password here is not a user password, but a certificate password


Keep the default length and click “next”


Click Next


Select the key type and directory and click Finish


The key file is generated in the specified directory.


Where identity is the private key file, Is a public key file.

(2) Upload the public key file to the server

You can upload to the server root directory through the securefx or xftp explained previously (if you don’t know how to operate or forget, please refer to the third part of this series of tutorials).

Upload to the Copy the public key file to the. SSH directory and name it authorized_ keys

[[email protected] .ssh]# ls
[[email protected] .ssh]# cat >>authorized_keys
[[email protected] .ssh]# ls

The reason you want this file to be named authorized_ Keys is because openssh does not support the key format generated by SecureCRT and requires type conversion.

(3) The server is forbidden to log in by account password

So far, you can use SecureCRT on windows to log in by certificate, but in order to ensure security and eliminate demonstration interference, we forbid the server to log in by account password

[[email protected] ~]# vi /etc/ssh/sshd_config 
Omit part of
PasswordAuthentication no
Omit part of
[[email protected] ~]# systemctl restart sshd.service 
[[email protected] ~]#

(4) Setting certificate login in SecureCRT

Set in session options


Set the directory where the certificate is located


Select the private key file generated in the first step, and then click “OK” to finish the setting.


At this time, you can log in successfully, using the certificate mode just now.

In addition, if the SecureCRT tool connects to multiple servers, which was just set through the global session option, it will first log in with a certificate by default, and if the login fails, it will try to log in with an account password. As shown in the following illustration, 100 server does not have certificate login set, but because the global setting has certificate login set, it will log in with certificate first, and the result indicates failure. Then, after adding skip, it will continue to log in with account password. As follows:


After clicking skip, you will be asked to log in with the account password again.

1.4 SCP command

CP command is used for local copy and SCP command is used for copying data between hosts. SCP, or secure copy, is a command for secure transmission between networks based on SSH protocol. The data it transmits is encrypted.

Syntax format:

SCP [parameter] local file remote account @ remote IP address: remote directory

If a password free login has been set between hosts, the remote account can be omitted, which is simplified as:

SCP [parameter] local file remote IP address or host name: remote directory


parameter function
-v Show detailed connection progress
-P Specify the sshd port number of the remote host. If it is the default port 22, you can not specify this parameter
-r Recursively transferring files for transferring folders


(1) Copy local files to remote host

[[email protected] ~]# echo "local to remote">local.txt
[[email protected] ~]# scp local.txt
The authenticity of host ' (' can't be established.
ECDSA key fingerprint is c1:b8:67:1f:1d:c0:cd:6b:37:90:42:b1:c6:5a:e8:cf.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '' (ECDSA) to the list of known hosts.
[email protected]'s password: 
local.txt                                     100%   16     0.0KB/s   00:00

Create a file locally, specify the relative path of the file through SCP command, and then transfer it to the remote host. At this time, log in to the remote host to view the file and transfer it.

In addition, the above demonstration is that SSH password free login is not set between hosts, so password is required. If password free login is set, password will not be required.

In addition, both absolute path and relative path can be used for local files. The relative path is displayed on the top, and we use absolute path to transfer.

[[email protected] ~]# scp /root/local.txt
[email protected]'s password: 
local.txt                                     100%   16     0.0KB/s   00:00 
[[email protected] ~]#

(2) Remote host file download to local

[[email protected] ~]# rm -rf local.txt 
[[email protected] ~]# scp /root/
[email protected]'s password: 
local.txt                                     100%   16     0.0KB/s   00:00 
[[email protected] ~]# ls
local.txt   ... omit some others

This shows that the files of the remote host have been copied to the local successfully. Remote copy files need to specify an absolute path to the remote file.

2、 Screen tool use

2.1 screen overview

2.1.1 background of screen

Have you ever run a long running task on a remote computer, and suddenly the connection is broken, the SSH session is terminated, and your work is lost.

System administrators often need SSH or telent to log in to the Linux server remotely, and often run tasks that take a long time to complete, such as system backup, FTP transmission, etc. Usually we open a remote terminal window for each such task, because they take too long to execute. You have to wait for them to finish executing. During this period, you can’t close the window or disconnect. Otherwise, the task will be killed and everything will be half done.

Screen is to solve the problem of task termination caused by disconnection of this session.

2.1.2 screen overview

Screen is an open source service program that can realize the remote control of multiple windows. In short, it is designed to solve the network abnormal interruption or to control multiple remote terminal windows at the same time.

Screen is a terminal multiplexer, which means that you can start a screen session, and then open any number of windows (virtual terminals) in the session. Even if you disconnect, the process running on screen will continue to run when its window is not visible.

2.1.3 screen installation

In rhel7 system, the screen service program is not installed by default and needs to be installed manually.

You can check whether screen is installed by the following command

[[email protected] ~]# screen --version
bash: screen: command not found...
[[email protected] ~]#

Install via yum

[[email protected] ~]# yum install screen
Loaded plugins: fastestmirror, langpacks
base                                                     | 3.6 kB     00:00 
Omit part of
  screen.x86_64 0:4.1.0-0.25.20120314git3c2946.el7                         
[[email protected] ~]# screen --version  
Screen version 4.01.00devel (GNU) 2-May-06
[[email protected] ~]#

After successful installation, you can see that the version is 4.01.

2.2 grammar

Syntax format:

Screen [parameter] session name

Common parameters:

parameter effect
-S Create session window
-r Reply to the specified session
-x Resume all sessions at once
-ls Show existing sessions

Execution mode:

You can create a session window through screen – s, and then perform tasks in the window. You can also follow the command to be executed directly after the screen command, so that the screen session will automatically end after the command is executed.

2.3 session management function

2.3.1 create session
[[email protected] ~]# screen -S first

Pay attention to the observation. At this time, the screen will flash quickly, and then there will be no movement. In fact, this has entered the first session window just created. Execute the following command to verify

[[email protected] ~]# screen -ls
There is a screen on:
        48917.first     (Attached)
1 Socket in /var/run/screen/S-root.
[[email protected] ~]#
2.3.2 exit the session

You can exit the first session by executing the exit command in the window just now

[[email protected] ~]# exit
[screen is terminating]
[[email protected] ~]#

In addition, when creating a session, you can also directly follow the command with the task to be executed, so you do not need to create the session first, and then start to work. All operations in the command will also be recorded, and the screen session will automatically end when the command is executed. The demonstration is as follows:

[[email protected] ~]# screen vim test.txt
"test.txt" [New] 1L, 6C written                               
[screen is terminating]
[[email protected] ~]#

Create a test.txt File, save and exit VIM, and then exit the session automatically.

2.3.2 session recovery

The so-called session recovery refers to the abnormal disconnection of the session, such as forcibly closing the session window, disconnecting the network, etc., rather than exiting the window or session through the exit normal command. If you exit normally, you can’t see the session information through screen ls, and you can only see and recover it in case of abnormal disconnection.

Create a session first and perform a task to view the log file

[[email protected] ~]# screen -S test
[[email protected] ~]#tail -f /var/log/messages

In this case, directly disconnect or close the session window to simulate abnormal disconnection.

Log in to the system remotely again, view the last session in the session window and resume the session with the following command

[[email protected] ~]# screen -ls
There is a screen on:
        49170.test      (Detached)
1 Socket in /var/run/screen/S-root.
[[email protected] ~]# screen -r test
[[email protected] ~]# tail -f /var/log/messages
Jan  5 19:40:01 origin systemd: Starting Session 77 of user root.
Jan  5 19:40:01 origin systemd: Started Session 77 of user root.
Jan  5 19:42:37 origin systemd-logind: Removed session 76.
Jan  5 19:42:39 origin systemd-logind: New session 78 of user root.
Jan  5 19:42:39 origin systemd: Starting Session 78 of user root.
Omit part of

After resuming the session, you can see that the tail command is still executing, right?

In the traditional way, if you directly disconnect or close the session window, the command will be lost. That is to say, the next time you log in to the system, you will not see that the tail command is still executing. This is the use of screen. Even if the session is disconnected, the task will continue as long as the server host is not shut down.

2.4 member sharing function

In addition to the session recovery described earlier, screen has many other functions. Let’s take a look at the session sharing function.


Use SecureCRT to log in to the top 100 and 104 hosts respectively. Let’s take sharing 104 screen hosts as an example (because screen has been installed on 104)

2.4.1 from 100 host SSH to 104
[[email protected] ~]# ssh
[email protected]'s password: 
Last login: Sun Jan  5 20:41:31 2020 from
[[email protected] ~]# screen -S test
2.4.2 execute screen command on 104 host
[[email protected] ~]# screen -x
2.4.3 viewing screen sharing

Any operation performed on 104 machine can be seen on 100, and similarly, any operation performed on 104 can be seen on 100.


In this way, screen sharing is realized, and only exit command is needed to exit.

Starting from the next article, we will introduce various services deployment under Linux, including vsftp file transfer service, postfix mail system, Apache Web service, etc. Please wait!