M, Socat and VNC. Oh, my God! Although being able to work remotely has always been one of the favorite advantages of Linux for system programmers and administrators, setting up remote access is not a simple matter. After choosing the right remote service, there is the second topic: security. Your server should be physically isolated, all unnecessary network access should be disabled, and the server can only be accessed through ssh or better. It is particularly worth mentioning that real-time telnet, ftp, rlogin, rsh and related services are used as little as possible; They are too dangerous. First of all, of course you should try. Programmers and administrators can work in their quiet workplaces during normal working hours, but they like to force themselves to complete these tasks suddenly, which is famous. Don't let yourself be the victim of such behavior! Make sure that the connection you have established has a legitimate business purpose and is not illegal. However, if you have encountered these organizational problems in the past, the answer to the connection problem is to use ssh. Even if you rely more on virtual private network (VPN) than ssh in principle, I still think that if you can't use conventional methods, it will be more cautious to set up ssh access in an emergency. VPN is still a bit difficult to handle and needs to rely on special hardware configuration. If you call the host through the client's network (mostly using an ordinary desktop), your options will be extremely limited. Ssh meets the requirements. The good news is that ssh usually meets the requirements in the cracks of these restrictions. Even if you are on a business trip, you may still have enough resources for ssh to work in public access points (such as Internet cafes). You may not be able to rely on your own equipment. Seriously speaking, carrying anything bigger than a handheld device around is another security risk; To make matters worse, foreign hardware is not allowed in many places. You usually have to use the hardware provided to you. But downloading puTTY, ssh or MindTerm clients is usually very fast. I like doing this. Any host that has enough network stacks to connect to your server room may have a Web browser that allows downloading. Be careful when using the installed client; For some people, it is too easy to replace the client with a modified client that can capture keystroke information (or worse). Another way is to construct a web page with an embedded MindTerm client as a small program, which looks attractive on the surface. And my experience tells me that this method is useless. Java is disabled in most places, or only the browser of the old Java runtime engine (JRE) is provided, or the convenience of applet is reduced in other ways. If I want to use MindTerm, I just want to download and install the client and a compatible JRE. Applet are usually a good technology to build applications for end users. Applets are also suitable for read-only configurations. However, I find this usage very rare. Therefore, in order to make your work efficient, it is not worth spending time to solve the possible problems in the small program environment. I always think it is more convenient to find a megabyte of free mass storage and install an ssh client. After you sit down for a while, you should install a new ssh client and start it. However, this may not be enough. In some places, firewalls close most ports, or at least many ports, including ssh's standard port 22. This is another way to be prepared to help. On at least one of my hosts, I want to assign sshd(ssh daemon) to common Internet services (such as ftp, cat or socat) and point it to the standard ssh port of the local host. This method is very useful in running experiments and tuning logging or extra security. Proxy in this context is a small converter, which just lets network traffic pass through. If I set up a sshd server on port 22 and want to set up another sshd server on port 1 10, one way to realize this idea is to install a network proxy. This proxy is used as a server on port 1 10 to receive traffic from the outside world. It processes these packets by acting as a client on port 22. The basic sshd server does all the practical work; The role of the proxy is only to switch from one port to another (possibly on another host). The real value of this special column lies not in abstruse code, but in conveying a clear concept, which you should aim at to enable your own remote service. I tried many ways. Take advantage of these experiences, especially the things not to do, at least when you set up the server room for the first time: forbid Telnet, don't always open unused services, don't worry about small programs (especially small program signatures), and don't log in remotely if you feel something is wrong. On the other hand, we must use standard parts. I tried many clever ideas to adjust ssh protocol or my own firewall to stop black hat hackers. Compared with the small security enhancements provided by these ideas, they are more difficult to maintain, so some of them are not worth the cost. Unless I have a clear budget and a clear long-term goal for the security project, I'd better spend my time using ssh instead of trying to improve it. With the above steps, you have a server room, and its security is much better than when you only use standard Linux servers for installation. You can also manage it remotely from almost all synchronous connections around the world.