SSH principle and application (i) and (ii): remote login RSA algorithm principle (i) and (ii)

SSH principle and application (i) and (ii): remote login RSA algorithm principle (i) and (ii)

Http://www.ruanyifeng.com/blog/2011/12/ssh_remote_login.html

Http://www.ruanyifeng.com/blog/2011/12/ssh_port_forwarding.html

Principles of RSA Algorithm (i.)

Http://www.ruanyifeng.com/blog/2013/06/rsa_algorithm_part_one.html

Principles of RSA Algorithm (II.)

Http://www.ruanyifeng.com/blog/2013/07/rsa_algorithm_part_two.html

SSH is the standard configuration for every Linux computer.

With the gradual expansion of Linux devices from computers to mobile phones, peripherals and home appliances, SSH is becoming more and more widespread. Not only is the programmer inseparable from it, but many ordinary users also use it daily.

SSH has a variety of functions and can be used in many situations. Some things, without it is impossible. This article is my study notes, summarizes and explains the common use of SSH, hope to be useful to everyone.

Although this article covers only primary applications, it is relatively simple, but requires the reader to have the most basic "shell knowledge" and understand the concept of "public key cryptography". If you are unfamiliar with them, I recommend reading the Unix/linux beginner tutorial and what is a digital signature? 》。

=======================================

SSH principle and application

Nanyi

One, what is SSH?

Simply put, SSH is a network protocol that is used to encrypt logins between computers.

If a user logs on to another remote computer using the SSH protocol from the local computer, we can assume that the login is secure, and that the password will not be compromised even if intercepted in the middle.

The earliest time, the Internet communication is clear communication, once intercepted, the content is undoubtedly exposed. In 1995, Finnish scholar Tatu Ylonen designed the SSH protocol to encrypt all login information and become a basic solution for Internet security, which has become a standard configuration for Linux systems.

It should be noted that SSH is only a protocol, there are many implementations, both commercial and open source implementation. The implementation of this article is OpenSSH, it is free software, the application is very extensive.

In addition, this article only discusses the use of SSH in a Linux shell. If you want to use SSH in a Windows system, you'll use another software putty, which you'll need to explain in another article.

Second, the most basic usage

SSH is primarily used for remote logins. Suppose you want to log in to the remote host hostname with the username user, as long as a simple command is available.

$ SSH [email protected]

If the local user name matches the remote user name, the user name can be omitted at logon.

$ SSH Host

The default port for SSH is 22, which means that your login request is sent to port 22 on the remote host. Using the P parameter, you can modify this port.

$ ssh-p 2222 [email protected]

The above command indicates that SSH connects directly to port 2222 of the remote host.

Third, man-in-the-middle attack

SSH guarantees security because it uses public-key cryptography.

The whole process is this:

(1) The remote host receives the user's login request and sends its own public key to the user.

(2) The user uses this public key to encrypt the login password and send it back to the remote host.

(3) The remote host with its own private key, decrypt the login password, if the password is correct, consent to user login.

The process itself is secure, but when implemented, there is a risk: if someone intercepts a login request and then pretends to be a remote host, the fake public key is sent to the user, making it difficult for the user to discern the authenticity. Because unlike the HTTPS protocol, the public key of the SSH protocol is not notarized by the Certificate Authority (CA), that is, it is issued by itself.

It can be assumed that if an attacker is plugged in between a user and a remote host (for example, in a public WiFi zone), a forged public key is used to obtain the user's login password. Then use this password to log on to the remote host, then SSH security mechanism is gone. This risk is known as the "man-in-the-middle attack" (Man-in-the-middle attack).

How is the SSH protocol coping?

Four, password login

If you are logged in to the other host for the first time, the following prompt will appear:

$ SSH [email protected]

The authenticity of host ' host (12.18.429.21) ' can ' t is established.

RSA key fingerprint is 98:2e:d7:e0:de:9f:ac:67:28:c2:42:2d:37:16:58:4d.

Is you sure want to continue connecting (yes/no)?

This passage means that you cannot confirm the authenticity of the host computer, only know its public key fingerprint, ask you still want to continue to connect?

The so-called "public key fingerprint", refers to the long public key length (here using the RSA algorithm, up to 1024-bit), it is difficult to compare, so the MD5 calculation, it becomes a 128-bit fingerprint. The above example is 98:2e:d7:e0:de:9f:ac:67:28:c2:42:2d:37:16:58:4d, and then compare, it is much easier.

A natural question is, how do users know what the remote host's public key fingerprint should be? The answer is no good way, the remote host must be posted on their own web site public key fingerprint, so that users self-check.

The user decides to accept the public key of the remote host, assuming that the user has passed the risk measurement himself.

Is you sure want to continue connecting (yes/no)? Yes

The system will appear with a hint that the host hosts have been recognized.

warning:permanently added ' host,12.18.429.21 ' (RSA) to the list of known hosts.

You will then be asked to enter a password.

Password: (Enter Password)

If the password is correct, you can log in.

When the public key of the remote host is accepted, it is saved in the file $home/.ssh/known_hosts. The next time you connect to this host, the system will recognize that its public key has been saved locally, thus skipping the warning section and prompting for a password directly.

Each SSH user has its own known_hosts file, and the system also has a file like this, usually/etc/ssh/ssh_known_hosts, that holds the public key for a remote host that can be trusted by all users.

Five, public key login

Log in with a password, you must enter the password every time, very troublesome. Fortunately, SSH also provides a public key login, which eliminates the steps to enter a password.

The so-called "public key Login" principle is simple, that is, the user stores their own public key on the remote host. When logged in, the remote host sends a random string to the user, which is encrypted with his or her private key and then sent back to the remote hosts. The remote host decrypts with a pre-stored public key and, if successful, proves that the user is trustworthy, allowing the login shell to be logged in and no longer requiring a password.

This approach requires the user to provide their own public key. If there is no ready-made, you can generate one directly with Ssh-keygen:

$ ssh-keygen

After you run the above command, a series of prompts will appear and you can return all the way. One of the questions is whether you want to set a password on the private key (passphrase), and if you are concerned about the security of the private key, you can set one here.

At the end of the run, the $home/.ssh/directory will be reborn into two files: Id_rsa.pub and Id_rsa. The former is your public key, and the latter is your private key.

Then enter the following command to transfer the public key to the remote host hosts:

$ ssh-copy-id [email protected]

OK, then you log in again, you do not need to enter the password.

If not, open the remote host's/etc/ssh/sshd_config this file, check the following lines before the "#" comment is removed.

Rsaauthentication Yes
Pubkeyauthentication Yes
Authorizedkeysfile. Ssh/authorized_keys

Then, restart the remote host's SSH service.

Ubuntu system
Service SSH Restart

Debian system
/etc/init.d/ssh restart

Vi.. authorized_keys file

The remote host stores the user's public key in the $home/.ssh/authorized_keys file of the user's home directory after logging in. A public key is a string, just append it to the end of the authorized_keys file ($HOME/.ssh/authorized_keys file can hold multiple public keys).

Instead of using the Ssh-copy-id command above, use the following command to explain the saving process for the public key:

$ SSH [email protected] ' mkdir-p. SSH && cat >>. Ssh/authorized_keys ' < ~/.ssh/id_rsa.pub

This command consists of multiple statements, broken down to see: (1) "$ ssh [email protected]", which means login to the remote host, (2) mkdir in single quotes. SSH && cat >>. ssh/authorized_ Keys, which indicates the command executed on the remote shell after login: (3) "$ mkdir-p. SSH" is used if the. SSH directory in the home directory does not exist, create one; (4) ' Cat >> Ssh/authorized_keys ' The function of < ~/.ssh/id_rsa.pub is to append the local public key file ~/.ssh/id_rsa.pub to the end of the remote file Authorized_keys.

After writing the Authorized_keys file, the settings for the public key login are complete.

==============================================

The section on remote login to the shell is written here, and the next time we go on to "remoting operations and port forwarding."

SSH principle and Application (ii): remote operation and Port forwarding

Nanyi

(Image credit: Tony narlock)

Seven, remote operation

SSH can be used not only for remote host logins, but also to perform operations directly on remote hosts.

The previous section of the operation is an example:

$ SSH [email protected] ' mkdir-p. SSH && cat >>. Ssh/authorized_keys ' < ~/.ssh/id_rsa.pub

The middle part of the single quotation mark, which represents the operation performed on the remote host, followed by an input redirect indicating that the data was passed through SSH to the remote host.

This means that SSH can create a transmission channel for commands and data between the user and the remote host, so many things can be done via SSH.

Let's look at a few examples.

"Example 1"

Copy all files under the $home/src/directory to the $home/src/directory of the remote host.

$ cd && tar czv src | SSH [email protected] ' tar xz '

"Example 2"

Copy all files under the remote host $home/src/directory to the user's current directory.

$ SSH [email protected] ' tar cz src ' | Tar Xzv

"Example 3"

See if the remote host is running process httpd.

$ SSH [email protected] ' PS Ax | grep [h]ttpd '

Viii. binding the port of the ground

Now that SSH can transmit data, we can improve security by allowing unencrypted network connections to go all the way to SSH connections.

Let's say that we want to have 8080 port data passed through SSH to the remote host, and the command reads:

$ ssh-d 8080 [email protected]

SSH will create a socket to listen to the local 8080 port. Once the data is transmitted to that port, it is automatically transferred to the SSH connection and destined for the remote host. As you can imagine, if port 8080 turns out to be an unencrypted port, it will now become an encrypted port.

Nine, local port forwarding

Sometimes, it is not enough to bind the port, and you must specify the destination host for the data transfer, thus forming a point-to-point "port forwarding". In order to differentiate the "Remote port Forwarding" later, we refer to this situation as "Local port Forwarding" (locally forwarding).

Assuming that Host1 is a local host, HOST2 is a remote host. For a variety of reasons, the two hosts are not connected to each other. However, there is also a host3 that can connect the front two hosts at the same time. So the natural idea is to connect host1 to Host2 through HOST3.

We execute the following command in Host1:

$ ssh-l 2121:host2:21 Host3

The l parameter in the command accepts a total of three values, namely "Local Port: Destination Host: Destination host port", separated by colons. The meaning of this command is to specify SSH to bind the port 2121, and then specify HOST3 to forward all data to 21 ports on the target host host2 (assuming HOST2 runs FTP, the default port is 21).

In this way, we simply connect the host1 2121 port, which is equal to the HOST2 21 port.

$ ftp localhost:2121

"Local port Forwarding" makes the host1 and host3 seem to form a secret tunnel of data transmission, and is therefore called the "SSH Tunnel".

Here is a more interesting example.

$ ssh-l 5900:localhost:5900 Host3

It indicates that the 5900 port of the native is bound to port 5900 of Host3 (this is HOST3, because the target host is relative to HOST3).

Another example is the port forwarding via HOST3, SSH login host2.

$ ssh-l 9001:host2:22 Host3

At this point, as long as SSH login to the 9001 port of this machine, it is equivalent to login host2.

$ ssh-p 9001 localhost

The-p parameter above indicates the specified login port.

Ten, remote port forwarding

Since "Local port forwarding" refers to the forwarding of the bound port, "Remote port Forwarding" (forwarding), of course, refers to the forwarding of the bound remote port.

Or continue to look at the above example, host1 and host2 can not be connected, must be forwarded with the help of Host3. However, special circumstances have arisen, HOST3 is an intranet machine, it can connect the host1 of the outside network, but in turn, the external network host1 not connected to the host3 of the intranet. At this time, "Local port Forwarding" can not be used, how to do?

The solution is, since host3 can even host1, then from the host3 to establish an SSH connection with host1, and then use this connection on the host1.

We execute the following command in HOST3:

$ ssh-r 2121:host2:21 host1

The R parameter also accepts three values, namely "Remote host Port: Destination Host: Destination host port". The meaning of this command is to let Host1 listen to its own 2121 port and then forward all the data through HOST3 to the port of Host2 21. Because Host1 is a remote host for HOST3, this is referred to as a "remote port binding".

After binding, we can connect host2 in host1:

$ ftp localhost:2121

It must be noted here that the "remote port forwarding" condition is that both the host1 and the Host3 two hosts have sshd and SSH clients.

Xi. other parameters of SSH

SSH also has some other parameters that are worth introducing.

The n parameter, which indicates that only the remote host is connected, does not open the remote shell;t parameter, indicating that no TTY is allocated for this connection. This two parameter can be used together, which means that the SSH connection is used only to transmit data and does not perform remote operations.

$ ssh-nt-d 8080 Host

The f parameter, which indicates that the SSH connection is successful and runs in the background. This allows you to perform other operations in the local shell without interrupting the SSH connection.

$ ssh-f-D 8080 Host

To close this background connection, you only kill the process with the kill command.

Port forwarding inside the Xshell

SSH principle and application (i) and (ii): remote login RSA algorithm principle (i) and (ii)