Linux ssh password-less access (2)

Linux ssh password-less access to the server end configuration has been completed, here to talk about the configuration on the client, it is relatively troublesome to configure the client on the server side, but be careful, in the end, Linux ssh has no password.

On the client

This is a representative question. Although it is relatively simple to write, it is easy to write.
Reference
Man ssh-add
Man ssh-keygen
Man ssh-agent

Use a public/private key for secure remote access

In the context of Digital Security, the key refers to a piece of data that is used to encrypt or decrypt other data fragments. The public key/private key mode is interesting because only the corresponding private key can be used to decrypt data encrypted with the public key. You can freely publish a public key so that others can encrypt the messages sent to you. One of the reasons that the public/private key mode completely changes digital security is that the sender and receiver do not have to share a common password. Among other contributions, public/private key encryption is possible through e-commerce and other secure transmission. In this article, we will create and use the public key and private key to create a very secure distributed backup solution.

Each machine in the backup process must run the OpenSSH Secure shell Service sshd), and port 22 can be accessed through any internal firewall. If you access a remote server, you may be using a secure shell.

Our goal is to securely access the machine without providing a password. Some people think that the simplest way is to set password-free access: Do not do this. This is not safe. The method we will use in this article may take about one hour, building a system that is as convenient as using a "password-free" account-is generally considered safe.

First, make sure that OpenSSH has been installed. Then, check the version number. At the end of this article, the latest OpenSSH release was February 24, 2004, which was released in 3.8. You should consider using a newer and stable release version. At least the version used should be newer than version 2.x. Visit the OpenSSH Security page to obtain details about the defects of a specific old version. So far, OpenSSH is very stable, and it has proved that there are no many defects reported by other SSH tools.

At the shell prompt, enter ssh and give an important V option to check the version number:
$ Ssh-V
OpenSSH_3.5p1, SSH protocols 1.5/2.0, OpenSSL 0x0090701f

If the version number returned by ssh is greater than 2.x, the machine is in a relatively good state. In any case, we recommend that you use the latest stable version for all your software, which is especially important for security-related software.

The first step is to log on to the offline storage server using an account that has the privilege to Access Server 1 and Server 2, as shown in Figure 1 ).
$ Ssh accountname@somedomain.com.

After logging on to the offline storage server, use the ssh-keygen program and provide the-t dsa option to create a public key/key pair. The-t option is required to specify the key type to be generated. We will use the Digital Signature Algorithm, DSA), which allows us to use the updated SSH2 protocol. Refer to the ssh-keygen manual for more details.

During ssh-keygen execution, you are prompted to enter the location of the ssh key storage before asking for your passphrase password. When querying where to store the key, you only need to press the Enter key, and then the ssh-keygen program will create a file named. ssh hidden directory if it does not exist), and two files, one public key file and one private key file.

An interesting feature of ssh-keygen is that when prompted to enter a password, it allows you to simply press the Enter key. If you do not provide a password, ssh-keygen will generate an unencrypted key! As you think, this is not a good idea. When a password is required, make sure that a long enough character message is entered. It is best to include a mix of characters, not just a simple password string.

Listing 3. Always select a password

[Offsite]: $ ssh-keygen-t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home/accountname/. ssh/id_dsa ):
Enter passphrase (empty for no passphrase): (enter passphrase)
Enter same passphrase again: (enter passphrase)
Your identification has been saved in/home/accountname/. ssh/id_dsa.
Your public key has been saved in/home/accountname/. ssh/id_dsa.pub.
The key fingerprint is:
7e: 5e: b2: f2: d4: 54: 58: 6a: fa: 6b: 52: 9c: da: a8: 53: 1b accountname @ offsite

Because the. ssh directory generated by ssh-keygen is a hidden "dot" directory, You need to input the-a option to the ls command to view the newly created directory:

[Offsite] $ ls-
... Bash_logout. bash_profile. bashrc. emacs. gtkrc. ssh

Go to the hidden. ssh directory and list its content:

[Offsite] $ cd. ssh
[Offsite] $ ls-lrt
Id_dsa id_dsa.pub

Now, in the hidden. ssh directory, we already have a private key id_dsa) and a public key id_dsa.pub ). You can use text editing tools such as vi or emacs or simply use the less or cat command to analyze the content of each key file. You will see that the contents composed of mixed characters are base64-encoded.

Then, we need to copy and install the public key on Server 1 and Server 2. Do not use ftp. It is more reasonable to use a secure copy program to transmit the public key to each remote machine.

Listing 4. Installing the public key on a remote server

[Offsite] $ scp. ssh/id_dsa.pub accountname@server1.com: offsite. pub
Accountname@server1.com's password: (enter password, not newpassphrase !)
Id_dsa.pub 100% | ***************************** | 614

[Offsite] $ scp. ssh/id_dsa.pub accountname@server2.com: offsite. pub
Accountname@server2.com's password: (enter password, not new passphrase !)
Id_dsa.pub 100% | ***************************** | 614

After installing the new public key, we can use the password specified when creating the private key and public key to log on to each machine. Now, log on to each machine and append the offsite. pub file to a file named authorized_keys, which is stored in the. ssh directory of each remote machine. We can use a text editor or simply use the cat command to append the content of the offsite. pub file to the authorized_keys file:

Listing 5. Add offsite. pub to the authorized Key List

[Offsite] $ ssh accountname@server1.com
Accountname@server1.com's password: (enter password, not new passphrase !)
[Server1] $ cat offsite. pub>./ssh/authorized_keys

The next step is to consider some additional security. First, we modify the access permissions of. ssh so that only the owner has the read, write, and execution permissions. Then, make sure that the authorized_keys file can only be accessed by the owner. Finally, delete the previously uploaded offsite. pub key file because it is no longer needed. It is important to set proper access permissions because the OpenSSH server may refuse to use keys with insecure access permissions.

Listing 6. Use chmod to modify permissions

[Server1] $ chmod 700. ssh
[Server1] $ chmod 600./ssh/authorized_keys
[Server1] $ rm offsite. pub
[Server1] $ exit

After completing the same steps on Server 2, we can return to the offline storage machine to test access with a new password type. On the offline server, you can enter the following content:
[Offsite] $ ssh-v accountname@server1.com

When checking that your account can now use a new password instead of the original password to access a remote server, use the-v or verbose flag option to display debugging information. The debugging output not only allows you to observe how the authentication process works at a high level, but also shows important information that you cannot obtain in other ways. In future connections, you may not need to specify the-v mark, but it is quite useful when testing the connection.

All the configurations for Linux ssh password-less access are completed here.

1. Linux ssh password-less access 1)
2. How to omit a password in Linux
3. Linux virus protection
4. Fully handle Linux syn Attacks
5. Detailed analysis of Linux System Network Services