Like the Telnet service, the SSH service can remotely log on to the system and control the system. However, it differs from Telnet in that Telnet transmits the transmitted content in plain text while SSH encrypts the transmitted content, ensuring the confidentiality of the transmitted content, this improves the system security. Here, I am not going to use the SSH service as a tool for uploading and downloading files. I only use the activation of the SSH service to facilitate the remote management system. In addition, in terms of user authentication
Like the Telnet service, the SSH service can remotely log on to the system and control the system. However, it differs from Telnet in that Telnet transmits the transmitted content in plain text while SSH encrypts the transmitted content, ensuring the confidentiality of the transmitted content, this improves the system security.
Here, I am not going to use the SSH service as a tool for uploading and downloading files. I only use the activation of the SSH service to facilitate the remote management system. In addition, in terms of user authentication, for the sake of server and user security, the user password authentication method is prohibited, and the "key" method is used.
Modify SSH-related configuration files
First, modify the SSH configuration file. As follows:
[Root @ 300 second ~] # Vi/etc/ssh/sshd_config using vi to open the SSH configuration file
# Protocol locate this row and delete the line header "#". then, delete ", 1" at the end of the line, and only allow connections in SSH2 mode.
Bytes
The Protocol 2 Protocol changes to this status after modification. only SSH2 is used.
# ServerKeyBits 768 rows find this line, remove "#" at the beginning of the line, and change 768 to 1024
Bytes
Changed ServerKeyBits 1024 bytes to this status, and changed ServerKeyBits to 1024 bits.
# PermitRootLogin yes locate this line, remove "#" at the beginning of the line, and change "yes" to "no ".
Bytes
PermitRootLogin no logs is changed to this status and cannot be logged on using root.
# PasswordAuthentication yes locate this line and change yes to no
Bytes
PasswordAuthentication no. login is changed to this status, and password-based logon is not allowed.
# PermitEmptyPasswords no longer find this row and delete the line header "#". empty password logon is not allowed.
Bytes
PermitEmptyPasswords no. changed to this status. do not log on with a blank password.
Save and exit. (The command for saving and exiting vi is ZZ)
Because we only want to make the SSH service more convenient for the management system, we only allow the intranet client to log on to the server through SSH without going through the Internet remote management system, to minimize unsafe factors. The setting method is as follows:
[Root @ 300 second ~] # Vi/etc/hosts. deny blocks modify the blocking rule and add corresponding lines at the end of the text
#
# Hosts. deny This file describes the names of the hosts which are
# ** Not * allowed to use the local INET services, as decided
# By the '/usr/sbin/tcpd' server.
#
# The portmap line is redundant, but it is left to remind you that
# The new secure portmap uses hosts. deny and hosts. allow. In particle
# You shoshould know that NFS uses portmap!
Sshd: ALL clients add this line to shield all ssh connection requests.
[Root @ 300 second ~] # Vi/etc/hosts. allow modify permit rules and add corresponding lines at the end of the text
#
# Hosts. allow This file describes the names of the hosts which are
# Allowed to use the local INET services, as decided
# By the '/usr/sbin/tcpd' server.
#
Sshd: 192.168.1. allow add this line, only allow SSH connection requests from the intranet
[Root @ 300 second ~] # Service sshd restart the SSH server
At this time, on the remote terminal (personal PC, etc.), you cannot log on to the server by using the SSH client software with a normal password. In order for the customer to log on to the server, we will create a public key and private key for SSH to log on to the SSH server as a "key" for the client.
Establishment of the public key and private key of SSH2
Logon is a common user who establishes a public key and a private key based on the user. (Here we use centos users as an example)
[Root @ 300 second ~] # Log on to the su-centos platform as a common centos user
[Centos @ 300 second ~] $ Ssh-keygen-t rsa KeyStore creates a public key and a private key
Generating public/private rsa key pair.
Enter file in which to save the key (/home/centos/. ssh/id_rsa): specifies the file name of the KeyStore key. press Enter by default.
Created directory '/home/centos/. ssh'
Enter passphrase (empty for no passphrase): Enter your password
Enter same passphrase again: Enter the password again
Your identification has been saved in/home/centos/. ssh/id_rsa.
Your public key has been saved in/home/centos/. ssh/id_rsa.pub.
The key fingerprint is:
89: b5: f7: 3a: cf: e4: 6f: a4: d7: 26: f3: 6d: b4: f7: 18: f1 centos @ 300 second
Then confirm the establishment of the public key and the key, and some processing corresponding to the client.
[Centos @ 300 second ~] $ Cd ~ /. Enter the Directory of the user's ssh configuration file.
[Centos @ 300 second. ssh] $ ls-l lists objects
Total 8
-Rw ------- 1 centos 1743 11-18 id_rsa Keys confirm that the private key has been created
-Rw-r -- 1 centos 398 11-18 0id_rsa.pub encrypt: check that the public key has been created
[Centos @ 300 second. ssh] $ cat ~ /. Ssh/id_rsa.pub> ~ /. Ssh/authorized_keys export public key content to the corresponding file
[Centos @ 300 second. ssh] $ rm-f ~ /. Ssh/id_rsa.pub KeyStore delete the original public key file
[Centos @ 300 second. ssh] $ chmod 400 ~ /. Ssh/authorized_keys secret set the attribute of the new public key file to 400
[Centos @ 300 second. ssh] $ exit logging out of normal user logon (return to root logon)
Then, the private key is securely transferred to the PC on which you want to connect to the server through SSH. Copy the file to the remote management client through a USB flash drive.
[Root @ 300 second ~] # Fdisk-l
Disk/dev/sda: 21.4 GB, 21474836480 bytes
255 heads, 63 sectors/track, 2610 cylinders
Units = cylinders of 16065*512 = 8225280 bytes
Device Boot Start End Blocks Id System
/Dev/sda1*1 13 104391 83 Linux
/Dev/sda2 14 78 522112 + 82 Linux swap/Solaris
/Dev/sda3 79 1990 15358140 83 Linux
Disk/dev/sdb: 2021 MB, 2021654528 bytes
255 heads, 63 sectors/track, 245 cylinders
Units = cylinders of 16065*512 = 8225280 bytes
Device Boot Start End Blocks Id System
/Dev/sdb1 1 245 1967931 B W95 FAT32
[Root @ 300 second ~] # Mkdir/mnt/usb
[Root @ 300 second ~] # Mount/dev/sdb1/mnt/usb
[Root @ 300 second ~] # Cd/mnt/usb
[Root @ 300 second usb] # cp/home/centos/. ssh/id_rsa.
In this way, we can connect to the server through the SSH client on a remote terminal through the private key corresponding to the centos user. However, the private key generated by the server cannot be directly applied by the client... For details, see the next page.
When the SSH service on the server runs normally, we can log on to the server on our own PC using the SSH client software in the LAN. in this way, the server will be configured and maintained in the future. Not strictly speaking, the server does not need a display or keyboard, because the vast majority of configuration work can be controlled on the remote (Lan) client.
InUse OpenSSH to build an SSH server (on) in CentOS 5.5)In this section, the private key of the corresponding user on the server is moved to the remote terminal (management PC) using a USB flash drive as the media, the following describes how to download the remote terminal and log on to the server using the SSH client software.
Here, PuTTY, one of the common and easy-to-use SSH client software, is used as an example to describe how to log on to the server from a PC. However, PuTTY cannot directly use the private key directly generated by the server. you need to use PuTTYGen to convert it to a private key that can be used by PuTTY.
[1] Download the private key conversion tool puttygen.
[2] run puttygen. the following window is displayed:
[3] Click Load to select the private key generated by the server (select "All Files" for the file type "). As follows:
[4] start to convert the private key. enter the password used to create the private key on the server. Enter the password in the text box to start conversion, as shown below:
[5] If the conversion is successful, a prompt window is displayed, and click "OK" to go to the next step. As follows:
[6] Save the converted private key to the appropriate location (the converted private key will be used as the private key when PuTTY logs on to the server ). Click "Save private key" and select an appropriate location to Save the private key. As follows:
Finally, disable puttygen and use PuTTY to remotely log on to the server.
[1] double-click to start PuTTY, find Auth (authentication method) on the left side, and set the private key used for the connection, as shown below:
[2] Click Browse and select the private key that has just been converted using puttygen. As follows:
[4] click Session on the left to return to the settings of host connection information. The settings are as follows:
[5] After saving, the added connection is displayed in the "Saved Sessions" column. Double-click the connection to start the connection.
[6] then enter the username of the corresponding user on the server in the login window, as shown below:
[7] After the user name is entered, no prompt box is displayed, because in the SSH server configuration, SSH login using the user password is forbidden. At this time, a prompt is prompted to enter the password, which is the password set when the server establishes the private key of the corresponding user (centos. Enter the password to log on. As follows:
[8] After entering the password, you can log on successfully as follows:
The above steps allow you to successfully log on to the server using the "key" method.
PS:
1) because the root user is not allowed to log on directly from the remote server when the SSH server is set, the SSH client cannot be used to log on through the root server. In addition, a user must be allowed to log on to the server, you must create a public key and private key based on a user, because I disable the user from logging on to the SSH server through password authentication, which greatly enhances the security of the server.
2) as a system administrator, you can add a general user to the wheel group and create a public key based on the general user to remotely log on, then run the "su-" command to obtain the root permission and configure the system. In addition, in the initial environment settings, we do not allow users outside the wheel Group to log on as root users, which further enhances the system security.