SSH user guide for Linux

Article title: guide to using SSH in Linux. Linux is a technology channel of the IT lab in China. Includes basic categories such as desktop applications, Linux system management, kernel research, embedded systems, and open source.

　What is SSH?

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.

The full name of SSH is Secure SHell. By using SSH, you can encrypt all transmitted data so that the "man-in-the-middle" attack method is impossible and can also prevent DNS and IP spoofing. Another advantage is that the data transmitted is compressed, which can speed up transmission. SSH has many functions. it can replace telnet and provide a secure "channel" for ftp, pop, and even ppp ".

SSH was initially developed by a Finnish company. However, due to copyright and encryption algorithm restrictions, many people have switched to OpenSSH. OpenSSH is an alternative to SSH and is free of charge. it is expected that more and more people will use it instead of SSH in the future.

SSH is composed of the client and server software. There are two incompatible versions: 1.x and 2.x. The client program using SSH 2.x cannot connect to the service program of SSH 1.x. OpenSSH 2.x supports both SSH 1.x and 2.x.

How does SSH security verification work? from the client perspective, SSH provides two levels of security verification.

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.

The second level (key-based security verification) depends 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 in the home directory of 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.

　　Install and test OpenSSH

Due to restrictions imposed by US law, OpenSSH is not included in many Linux distributions. However, you can download and install OpenSSH from the network (for OpenSSH installation and configuration, see linuxaid.com.cn/engineer/brimmer/html/OpenSSH.htm "> http://www.linuxaid.com.cn/engineer/brimmer/html/OpenSSH.htm ).

After OpenSSH is installed, run the following command to test it:

Ssh-l [your accountname on the remote host] [address of the remote host]

If OpenSSH works properly, you will see the following prompt:

The authenticity of host [hostname] can't be established. key fingerprint is 1024 5f: a0: 0b: 65: d3: 82: df: AB: 44: 62: 6d: 98: 9c: fe: e9: 52. are you sure you want to continue connecting (yes/no )?

OpenSSH tells you that it does not know this host, but you do not have to worry about this problem, because it is the first time you log on to this host. Type "yes ". This will add the "recognition mark" of this host to "~ /. Ssh/know_hosts "file. This prompt is no longer displayed when you access this host for the second time.

Then, SSH prompts you to enter the password of your account on the remote host. After the password is entered, an SSH connection is established, and then SSH can be used as via telnet.

　　SSH key

Generating your own Keys has two benefits for generating and distributing your keys: 1) preventing man-in-the-middle attacks

2) you can use only one password to log on to all servers you want to log on.

Use the following command to generate a key:

Ssh-keygen

If the remote host uses SSH 2.x, use this command:

Ssh-keygen? D

There is no problem with SSH1 and SSH2 keys on the same host, because the keys are saved into different files.

The following information is displayed after the ssh-keygen command is run:

Generating RSA keys :...... OoooooO ...... OoooooO Key generation complete. enter file in which to save the key (/home/[user]/. ssh/identity): [press ENTER.] Created directory '/home/[user]/. ssh '. enter passphrase (empty for no passphrase): [the entered password is not displayed on the screen] Enter same passphrase again: [Enter the password again, if you forget the password, you can only regenerate the key once.] Your identification has been saved in/home/[user]/. ssh/identity. [This is Your private key] Your public key has been saved in/home/[user]/. ssh/identity. pub. the key fingerprint is: 2a: dc: 71: 2f: 27: 84: a2: e4: a1: 1e: a9: 63: e2: fa: a5: 89 [user] @ [local machine]

"Ssh-keygen? D "does almost the same thing, but saves a pair of keys as (by default)"/home/[user]/. ssh/id_dsa "(private key) and"/home/[user]/. ssh/id_dsa.pub "(public key ).

Now you have a pair of keys: public keys should be distributed to all remote hosts that you want to log on with ssh. private keys should be kept properly to prevent others from knowing your private keys. Use "ls? L ~ /. Ssh/identity "or" ls? L ~ /. Ssh/id_dsa "indicates that the object access permission must be"-rw --".

If you suspect that your key has been known by others, do not hesitate to generate a new key immediately. Of course, you have to resend the public key.

　　Distribute public keys

On each remote server that you need to connect to by using SSH, you need to create a ". ssh sub-directory, put your public key "identity. copy pub to this directory and rename it "authorized_keys ". Then execute:

Chmod 644. ssh/authorized_keys

This step is essential. SSH will not work unless you have the write permission on the "authorized_keys" file.

If you want to log on to a remote host from a different computer, the "authorized_keys" file can also have multiple public keys. In this case, you must re-generate a pair of keys on the new computer, copy and paste the generated "identify. pub" file into the "authorized_keys" file of the remote host. Of course, you must have an account on the new computer, and the key is password-protected. It is very important that you do not forget to delete this pair of keys after you cancel this account.

[1] [2] [3] Next page