Millet Porridge

English version of https://corvo.myseu.cn

0%

Termux Phone Ops

Posted on Edited on In Disqus:
This blog only introduces one convenient remote solution; it doesn't cover concrete ops problem handling

My phone is a OnePlus7 Pro with the official system, not rooted, with only the Termux app installed

The Original Intent

I wrote two blogs before:

Recently I thought about it: native termux’s functionality is definitely not as strong as native Linux. So I want to run a separate Linux system on the phone, then use frp for tunneling to expose the ssh port to the public network. The phone runs Linux and is accessible anytime, anywhere.

A Simple linux Environment

In the last blog Running vscode_remote on Android, anyfed could already run the fedora system; the principle is proot. This time I was smarter and directly searched proot linux.

I found this part of the official wiki:

https://wiki.termux.com/wiki/PRoot

You can directly use proot-distro to run and start systems:

1
2
proot-distro install <alias>
proot-distro login <alias>

ssh Service and frp Service

ssh service

Mainly you need to edit /etc/ssh/sshd_config.

Port 22 is definitely unusable, so I switched to 8122. On the phone everything runs as root by default, and the root user also needs password login allowed:

PermitRootLogin yes

frp service

Using frp is mainly to map my port to the public network so I can connect anytime anywhere. The token and server_addr need to be prepared in advance yourself.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
[common]
server_addr = 192.168.12.32
server_port = 7000
token = xxxxxx

[ssh-mi_ssh]
type = tcp
local_ip = 127.0.0.1
local_port = 8122
remote_port = 7001

# Enable TCP health check
health_check_type = tcp
# TCPing timeout seconds
health_check_timeout_s = 3
# If health check failed 3 times in a row, the proxy will be removed from frps
health_check_max_failed = 3
# A health check every 10 seconds
health_check_interval_s = 10

Service Startup and Daemon Processes

Since we use proot, it’s not a complete Linux system — there’s no way to use systemd for daemon processes. Left with no choice, I chose supervisor for service management; currently it only manages sshd and frp.

In .bashrc, if supervisor isn’t running, start it:

1
2
3
if [ ! -f /proc/$(cat /var/run/supervisord.pid)/status ]; then
    service supervisor start
fi

After starting supervisor, I found supervisorctl couldn’t connect — mainly a unix socket reading problem; proot has rather many restrictions. My replacement solution here: switch to a tcp port.

Main modification: /etc/supervisor/supervisord.conf

1
2
3
4
5
6
7
8
9
10
11
12
[inet_http_server]
port = 127.0.0.1:3000

# comment out the unix socket
# [unix_http_server]
# file=/var/run/supervisor.sock   ; (the path to the socket file)
# chmod=0777 ; sockef file mode (default 0700)

[supervisorctl]
# comment out the unix socket; use a tcp port instead
# serverurl=unix:///var/run/supervisor.sock ; use a unix:// URL  for a unix socket
serverurl=http://127.0.0.1:3000 ; use a unix:// URL  for a unix socket
1
2
3
4
# now running the command works normally
root@localhost ~$ supervisorctl
frpc                             RUNNING   pid 10892, uptime 0:14:28
sshd                             RUNNING   pid 10894, uptime 0:14:28

Discussion of Security and Usability

Security

Reviewing the operations in the blog just now, can you count how many unsafe operations I have? Let me list them:

  1. Daily operations as the root user
  2. PermitRootLogin yes allows root password login
  3. After frp tunneling, the IP and port exposed to the public network
  4. supervisor using a tcp socket means all users on the machine have management privileges

I suggest everyone absolutely never use the above practices at work!!!

Since I use proot inside Termux, this root privilege has very little capability, so it can be used this way; there are no other users in this system, and supervisor can also be used directly like this.

frp tunneling only happens when I start the app — that is, with Termux normally closed, no port is exposed to the public network.

Usability

  1. Unlike using Termux directly, a fairly complete Linux system experience is much better: it has glibc, can run all kinds of Linux software — no different from a development server
  2. Customized startup and shutdown: for colleagues doing ops on the road with only a phone at hand (hardcore friends can even do ops directly on the phone). A more comfortable option is finding a computer in an internet cafe, ssh-ing to your own phone; vscode remote can also serve as a temporary development machine
  3. I normally install the company-provided VPN on the phone; termux can also go through the VPN, so this little Linux system gets the same experience as the office network

Summary

The blog just introduces a remote ops solution I use daily myself. I rarely carry a computer out; being able to run a Linux system on the phone is really much more convenient. Also, what a terminal alone can do is limited — the ops management web side should ideally have supporting facilities too, so problems outside working hours can be handled better and faster.

Related Posts