Shulou(Shulou.com)06/01 Report--

Default mode

If we want to log in to the remotehost host from the localhost host through SSH, execute the following command:

Ssh username@centos-i1

This is the default way for ssh to handle authentication, it will ask us to enter the password of username, if we enter the password, ssh will use the secure password authentication protocol to send our password to remotehost for authentication. However, unlike in the case of telnet, our password is encrypted here, so it will not be intercepted by people who secretly see our data connection. Once remotehost authenticates the password we provide with its password database, if successful, we will be allowed to log in.

Through the public and private key authentication of TSA and RSA

In order to use this authentication, we first have to generate a pair of keys: a private key and a public key. The public key is used to encrypt the message, and only the person with the private key can decrypt the message. Public keys can only be used for encryption, while private keys can only be used to decrypt messages encoded by matching public keys. RSA (and DSA) authentication protocols make use of these special properties of key pairs for secure authentication and do not need to transmit any confidential information on the Internet.

Then copy the public key to remotehost. One reason why a public key is called "public" is that it can only be used to encrypt messages that are given to us, so we don't need to worry too much about it falling into the hands of others. Once our public key has been copied into remotehost and placed in a special file (~ / .ssh/authorized_keys) so that remotehost's sshd can locate it, we are ready to log in to remotehost using RSA authentication.

To log in with RSA, as we often do, we just type ssh username@centos-i1 in the console of localhost. But this time, ssh tells remotehost's sshd that it wants to use the RSA or DSA authentication protocol. Remotehost's sshd generates a random number and encrypts it with the public key we copied earlier. Sshd then sends the encrypted random number back to the ssh running on the localhost. Next, it's localhost's ssh's turn to decrypt the random number with a private key, and then send it back to remotehost, which is actually saying, "look, I do have a matching private key; I can decrypt your message successfully!" . So remotehost's sshd concludes that since we have a matching private key, we should be allowed to log in.

Two points for attention

There are two important considerations for RSA and DSA certification.

We really only need to generate a pair of keys. Then we can copy our public key to the remote machines we want to access and configure the appropriate authentication. In other words, we don't need to prepare a pair of keys for every system we want to access. Just one pair is enough.

The private key should not fall into the hands of others. It is the private key that authorizes us to access the remote system, and anyone with our private key will be granted exactly the same privileges as we do. We should protect our private keys from unauthorized use.

The developers of ssh certainly know the importance of private keys, and they have added some precautions to ssh and ssh-keygen to prevent our private keys from being abused. First, ssh is set to print a large warning message if the file permissions of our key allow anyone but us to read the key. Second, when we create a public / private key pair with ssh-keygen, ssh-keygen asks us to enter a passphrase. If we enter a passphrase, ssh-keygen encrypts our private key with that passphrase, so that even if the private key is stolen, it is useless to those who happen not to know the passphrase.

Specific configuration steps

Take the host centos-i2 password-free login to centos-i1 as an example.

1. Generate public and private keys on the host centos-i2

[root@centos-i2 ~] # ssh-keygen # uses the RSA protocol by default, or you can use the DSA protocol with the-t dsa parameter

Generating public/private rsa key pair.

Enter file in which to save the key (/ root/.ssh/id_rsa):

Enter passphrase (empty for no passphrase): # enter directly here

Enter same passphrase again:

Your identification has been saved in/root/.ssh/id_rsa.

Your public key has been saved in/root/.ssh/id_rsa.pub.

The key fingerprint is:

33:3e:b4:b5:bb:76:e3:6d:c9:2a:53:93:24:31:0b:40root@centos-i2

This will generate two files, public and private keys, in the / home/.ssh directory as prompted by the program.

two。 Copy the generated public key file id_rsa.pub to the centos-i1 host

[root@ ce [root @ centos-i2 .ssh] # scpid_rsa.pub root@centos-i1:/root/.ssh

Root@centos-i1's password: # password-free settings are not ready at this time, so a password is required

Id_rsa.pub 100% 396 0.4KB/s 00:00

3. Configure the public key of centos-i2 on the centos-i1 host

[root@centos-i1 .ssh] # cat id_rsa.pub > > authorized_keys

After the configuration of the above three steps is complete, you can log in to centos-i1 without password ssh on centos-i2 through the ssh and scp commands. Examples are as follows:

[root@centos-i2 .ssh] # ssh root@centos-i1

[root@centos-i2 lb] # scp fio-2.2.10.tar.gzroot@centos-i1:/home/lb

However, since we do not use a passphrase to protect the private key in step 1, it may be risky if the private key is used improperly. To avoid the hidden dangers caused by this, you can use ssh-agent. About the use of ssh-agent, you can see the references.

Configuration of DSA Protocol Generation of DSA key

Version 1 of the ssh protocol uses the RSA key, while the DSA key is used for protocol level 2, which is the latest version of the ssh protocol. All current versions of OpenSSH should be able to use both RSA and DSA keys. The DSA key is generated using OpenSSH's ssh-keygen in the following manner similar to the RSA key:

% ssh-keygen-t dsa

We will also be prompted for a passphrase. Enter a secure passphrase. We will also be prompted to enter the location where the DSA key is saved. Normally, the default ~ / .ssh/id_dsa and ~ / .ssh/id_dsa.pub will be fine. After we have generated the DSA key at one time, it is time to install our DSA public key on the remote system.

Installation of DSA public key

The installation of the DSA public key is almost the same as the RSA installation. For DSA, we are going to copy the ~ / .ssh/id_dsa.pub file to remotehost, and then attach it to the ~ / .ssh/authorized_keys2 file on remotehost. Notice that the name of this file is different from the authorized_keys file name of RSA. Once configured, entering the passphrase of our DSA private key should be able to log in to remotehost without requiring us to enter the real password on remotehost.

reference

Https://www.ibm.com/developerworks/cn/linux/security/openssh/part1/index.html

Https://www.ibm.com/developerworks/cn/linux/security/openssh/part2/

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.