/* Traditional network service programs, such as FTP, pop, and telnet, are inherently insecure because they transmit passwords and data in plain text on the network, people with ulterior motives can easily intercept these passwords and data. In addition, the security authentication methods of these service programs also have their weaknesses, that is, they are vulnerable to man-in-the-middle attacks. The so-called "man-in-the-middle" attack means that "man-in-the-middle" impersonates a Real Server to receive the data you send to the server, and then impersonates you to pass the data to the Real Server. When the data transfer between the server and you is transferred by a man-in-the-middle, a serious problem may occur. By using SSH, You can encrypt all transmitted data, so that the "man-in-the-middle" attack method is impossible, and it can also prevent DNS Spoofing and IP spoofing. Another advantage of using SSH is that the data transmitted is compressed, which can speed up transmission. SSH has many functions. It can replace telnet, provide a secure "channel" for FTP, pop, and even PPP ".
From the client perspective, SSH provides two levels of security authentication.
Level 1 (password-based security verification)
You can log on to the remote host as long as you know your account and password. All transmitted data is encrypted, but it cannot be guaranteed that the server you are connecting to is the server you want to connect. Other servers may pretend to be real servers, that is, being attacked by man-in-the-middle.
Level 2 (key-based security verification)
You need to rely on the key, that is, you must create a pair of keys for yourself, and put the public key on the server to be accessed. If you want to connect to the SSH server, the client software will send a request to the server, requesting your key for security verification. After receiving the request, the server first looks for your public key under your home directory on the server, and then compares it with the public key you sent. If the two keys are consistent, the server uses the public key to encrypt the challenge and send it to the client software. After the client software receives a question, it can use your private key to decrypt it and then send it to the server. In this way, you must know your key password. However, compared with the first level, the second level does not need to transmit passwords over the network. The second level not only encrypts all transmitted data, but also the "man-in-the-middle" attack method is impossible (because he does not have your private key ). However, the entire logon process may take 10 seconds. SSH consists of three parts:
Transport Layer Protocol [SSH-TRANS]
Provides Server Authentication, confidentiality, and integrity. In addition, it sometimes provides the compression function. A SSH-TRANS typically runs on a TCP/IP connection and may also be used on other reliable data streams. SSH-TRANS provides strong encryption technology, password Host Authentication and Integrity protection. The authentication in this Protocol is based on the host and does not perform user authentication. Higher-level user authentication protocols can be designed on top of these protocols.
User Authentication Protocol [SSH-USERAUTH]
It is used to provide the client user identification function to the server. It runs on the transport layer protocol SSH-TRANS. When the SSH-USERAUTH starts, it receives session identifiers from low-level protocols (from swap hash H in the first key exchange ). The session identifier uniquely identifies the session and applies to the tag to prove the ownership of the private key. SSH-USERAUTH also needs to know whether low-level protocols provide confidentiality protection.
Connection Protocol [SSH-CONNECT]
Divides multiple encrypted tunnels into logical channels. It runs on the user authentication protocol. It provides interactive logon routes, remote command execution, forwarding TCP/IP connections, and forwarding X11 connections. */
yum install ssh
service sshd start
chkconfig sshd on
Modify ssh-related configuration files
First, modify the SSH configuration file. [Email protected] ~] # Vi/etc/ssh/sshd_config using vi open the SSH configuration file # protocol locate this line and delete the line Header "#", and then delete ", 1" at the end of the line, only the connection protocol Protocol 2 protocol in SSH2 mode is allowed to be changed to this State after modification. Only the line "#" at the beginning of the line is found using SSH2 # serverkeybits 768 protocol, change "768" to "1024 slave serverkeybits 1024 slave", and change "serverkey strength" to "1024 bits # permitrootlogin Yes slave" to find this line and remove "#" at the beginning of the line, change "yes" to "no such permitrootlogin no such modification" to this status. You are not allowed to log on using root. # passwordauthentication Yes. Find this line, change "yes" to "no signature passwordauthentication ". Status, password-based logon is not allowed # permitemptypasswords No. Find this line and delete the line Header "#". Do not allow a blank password to log on to the role permitemptypasswords No. Changed to this status, do not enter a password to log on and save and exit. (The command for saving and exiting VI is ZZ.) We only want to make the SSH service more convenient for the management system. Therefore, without the remote management system through the Internet, only Intranet clients are allowed to log on to the server through SSH to minimize insecure factors. The setting method is as follows: [[email protected] ~] # Vi/etc/hosts. modify the deny shield rule and add the corresponding line 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 Hosts add this line to shield all SSH connection requests [[email protected] ~] # Vi/etc/hosts. add the corresponding line 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.0. ← add this line, only allow SSH connection requests from the Intranet
After modifying the SSH configuration file, you must restart the SSH service to make the new settings take effect. [[Email protected] ~] #/Etc/rc. d/init. d/sshd restart the SSH server stopping sshd: [OK] Starting sshd: [OK] When the SSH server is restarted successfully, on the remote terminal (Personal PC, etc, you cannot log on to the server using the SSH client 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. The establishment of the public key and private key of SSH2 serves as a general user, and the establishment of a public key and private key based on this user. (For example, centospub users) [[email protected] ~] # Log on to the Su-centospub guest as a general user centospub [[email protected] ~] $ Ssh-keygen-t rsa keys create public keys and private keys generating public/private RSA key pair. enter file in which to save the key (/home/KAZ /. SSH/id_rsa): name of the keystore key file. Press ENTER Created directory by default /. SSH 'enter passphrase (empty for no passphrase): enter your password enter same passphrase again: enter your password again your identification has been saved in/home/KAZ /. SSH/id_rsa.your public key has been saved in/home/KAZ /. SSH/id_rsa.pub.the key fingerprint is: TF: RS: E3: 7 S: 28: 59: 5 S: 93: Fe: 33: 84: 01: CJ: 65: 3B: 8e [email protected] And then confirm
Public Key and key Creation
And some processing corresponding to the client. [[Email protected] ~] $ Cd ~ /. Enter the user's SSH configuration file directory [[email protected]. SSH] $ LS-l keys list the files total 16-rw --- 1 centospub 951 Sep 4 id_rsa keys confirm that the private key has been created-RW-r-1 centospub 241 Sep 4 19: 22 id_rsa.pub confirm that the public key has been created [[email protected]. SSH] $ cat ~ /. Ssh/id_rsa.pub> ~ /. Ssh/authorized_keys export public key content to the corresponding file [[email protected]. Ssh] $ Rm-f ~ /. Ssh/id_rsa.pub keystore Delete the original public key file [[email protected]. Ssh] $ chmod 400 ~ /. Ssh/authorized_keys secret sets the attribute of the newly created public key file to 400, and then securely transfers the Private Key to the PC to be connected to the server through SSH. Here, we use a 3.5-inch disk as an example: [email protected]. Ssh] $ exit quit to log on to a general user (return to the root logon) [[email protected] ~] # Mount/mnt/floppy/volumes attach a floppy disk drive [[email protected] ~] # Mv/home/centospub/. Ssh/id_rsa/mnt/floppy/secrets move the created private key to a floppy disk [email protected] ~] # Umount/mnt/floppy/uninstall detach a floppy disk
If Chinese characters are garbled, you only need to change the encoding in putty or securecrt to utf8.