TtyS0 to ttyS3 (serial port terminals) refer to the physical interfaces of the computer (these are serial ports, not parallel ports). External terminals are connected to the computer through these physical interfaces to interact with the computer.
For example: the dmesg | grep tty can view the open interface (serial)
At present, virtual terminals are created to connect to remote servers or operate on them directly. Examples include PTS /1 and TTy1 virtual terminals, where TTY means generated by a direct login machine and PTS means generated by a remote connection. The remote connection is through the SSHD service to create session sessions and bash processes (so you can see that there are SSHD processes and virtual terminals can create more than one at the same time, which depends on the PTMX function. SSHD communicates with PTMX, and PTMX communicates with the corresponding PTS to achieve the effect of multiple virtual terminals).
Such as: In the image interface of centos system, terminal is a PTS, but the entire graphical interface is a TTY. When centos switches to the command line interface and enters the tty command, the output is TTy1 or TTyn. In this case, the command line interface and graphical interface run at the same level. All processes created from the command line belong to the TTy1 terminal.
Note: TTY is a virtual version of ttyS, but it does not need to be connected via an external wire. Remote connection to the server requires SSHD service, there is no connection between SSHD and TTY, remote connection is due to the local terminal emulator, local connection requires the kernel to simulate a simulator directly, all remote is PTS, local is TTY.
As you can see from the flow above, there is no difference in user-space applications, they are all the same; From the kernel’s perspective, the other side of PTS connects to PTMX, while the other side of TTY connects to the terminal emulator of the kernel. Both PTMX and the terminal emulator are responsible for maintaining sessions and forwarding packets. Looking at the other end of PTMX and the kernel terminal emulator, the other end of PTMX connects to user-space applications such as SSHD, TMUX, etc., while the other end of the kernel terminal emulator connects to specific hardware such as the keyboard and display.
SSH Remote Access — key
“Terminal” can be anywhere, such as putty on Windows, so we won’t discuss how the client’s Terminal program interacts with the keyboard and monitor. Because Terminal needs to communicate with the SSH server, it must implement the SSH client function. Here, the connection establishment and data sending and receiving are explained in two lines. For the sake of concise description, SSHD is used instead of SSH server program:
Establish a connection:
1.Terminal Requests to establish a connection with the SSHD.
2. If the authentication succeeds, SSHD creates a new session.
3. Call API (posix_openPT ()) to request PTMX to create a PTS. After successful creation, SSHD will get the FD associated with PTMX and associate the FD with session.
4. At the same time, SSHD creates a shell process and binds the newly created PTS to the shell.
Sending and receiving messages:
1.Terminal Receives the keyboard input, and sends the data to the SSHD through SSH.
2. After receiving the data from the client, SSHD finds the FDS corresponding to the client associated with PTMX based on its own managed session.
3. Write the data sent by the client to the found FD.
4. After receiving the data, PTMX finds the corresponding PTS according to the FD (the corresponding relationship is automatically maintained by PTMX) and forwards the data packets to the corresponding PTS.
5. After receiving the data packet, the PTS checks the current front-end process group bound to it and sends the data packet to the leader of the process group.
6. Since there is only shell on the PTS, the shell’s read function receives the packet.
7. The shell processes the received packet and outputs the processing result (or none).
8. The shell writes the result to PTS via the write function.
9. PTS forwards the results to PTMX.
10. PTMX finds the corresponding FD based on PTS and writes the result to that FD.
11. After receiving the result of the FD, the SSHD finds the corresponding session and sends the result to the corresponding client.
SSH + Screen/Tmux
Those of you who use Linux are familiar with Screen and TMUx. If you start a process from screen and TMUx, it will continue to run even if the network is disconnected. The next time you connect to screen, you can see all the output of the process and continue to work. This is a bit more complicated, but the principle is the same. The first half of the process is the same as normal SSH, except that the front-end process associated with PTS-0 is changed to tMUx client instead of shell, so packets sent by SSH client are received by TMUx client. The TMUX client then forwards the data to the TMUX server, which, like SSH, maintains a bunch of sessions, creates a PTS for each session, and forwards the data sent by the TMUX client to the corresponding PTS. Since the TMUX server only deals with TMUx clients and has nothing to do with SSHD, when the terminal is disconnected from THE SSHD, the TMUX server will not be affected, although PTS /0 will be shut down and the shell and TMUx clients associated with it will be killed. The next time you connect the TMUx client to the TMUx server, you will see the same content as last time.