Can't install proxytunnel.

[Steve-Newcomb]

Problem description

I can't install proxytunnel under the Debian proot-distro. Indeed, apt "has been disabled permanently for safety purposes." I did install proxytunnel using the f-droid version of AnLinux, but when I switched to proot-distro, which seems like a fine project, I lost the ability to run proxytunnel. (Proxytunnel is unavailable under termux. My whole reason for using prooted-Debian is to gain the use of proxytunnel.)

I am aware that there are safety issues with installing packages in a proot environment. Isn't it true that similar issues pertain to the AnLinux app? And yet, AnLinux works for proxytunnel, while proot-distro does not.

Actually, there are safety issues with computer software generally, but that's not a good reason to completely prevent the use of computers. A stern lecture about the dangers is generally sufficient, and if it isn't, then the lecturee deserves what she gets.

What steps will reproduce the bug?

(1) Install proot-distro. (2) Log in/start. (3) Run apt. It doesn't work.

What is the expected behavior?

Apt should install proxytunnel if the distro's repo has it.

[Grimler91]

$ pkg in proot-distro
$ proot-distro install debian
$ proot-distro login Debian
root@localhost:~# apt update 
root@localhost:~# apt install proxytunnel

Works fine for me. There's nothing in proot-distro that disables apt for debian so unclear what you are seeing

[ghost]

Do you have the logs to post why proxytunnel/apt doesn't work or install?

[Steve-Newcomb]

Thanks for the rapid responses. Here's a run. I have sshd running under Debian/proot, so I log in using it as shown.

220211 11:02 /persist/home/srn srn@basil% ssh -p 2235 192.168.4.35
X11 forwarding request failed on channel 0
220211 11:02 /root root@punch% apt update
Ability to run this command as root has been disabled permanently for safety purposes.
220211 11:03 /root root@punch% apt install proxytunnel
Ability to run this command as root has been disabled permanently for safety purposes.
220211 11:03 /root root@punch% cat /var/log/syslog
cat: /var/log/syslog: No such file or directory
220211 11:03 /root root@punch% uname -a
Linux localhost 5.4.0-faked #0 SMP PREEMPT Wed Nov 24 10:04:17 UTC 2021 aarch64 Android
220211 11:07 /root root@punch% cat /etc/debian_version 
11.0
220211 11:07 /root root@punch% 

[Steve-Newcomb]

Here is the proot process command line as reported by ps axw:

26953 pts/4 S 0:00 proot -p --bind=/data/data/com.termux/files/usr/local/ch-tools3:/usr/local/ch-tools3 --bind=/data/data/com.termux/files/usr/tmp:/tmp --bind=/data/data/com.termux/files/home:/root --bind=/vendor --bind=/system --bind=/data/data/com.termux/files/usr --bind=/linkerconfig/ld.config.txt --bind=/apex --bind=/storage/self/primary:/sdcard --bind=/data/data/com.termux/files/home --bind=/data/data/com.termux/cache --bind=/data/dalvik-cache --bind=/data/data/com.termux/files/usr/var/lib/proot-distro/installed-rootfs/debian/tmp:/dev/shm --bind=/data/data/com.termux/files/usr/var/lib/proot-distro/installed-rootfs/debian/proc/.vmstat:/proc/vmstat --bind=/data/data/com.termux/files/usr/var/lib/proot-distro/installed-rootfs/debian/proc/.version:/proc/version --bind=/data/data/com.termux/files/usr/var/lib/proot-distro/installed-rootfs/debian/proc/.uptime:/proc/uptime --bind=/data/data/com.termux/files/usr/var/lib/proot-distro/installed-rootfs/debian/proc/.stat:/proc/stat --bind=/data/data/com.termux/files/usr/var/lib/proot-distro/installed-rootfs/debian/proc/.loadavg:/proc/loadavg --bind=/sys --bind=/proc/self/fd/2:/dev/stderr --bind=/proc/self/fd/1:/dev/stdout --bind=/proc/self/fd/0:/dev/stdin --bind=/proc/self/fd:/dev/fd --bind=/proc --bind=/dev/urandom:/dev/random --bind=/dev --root-id --cwd=/root -L --kernel-release=5.4.0-faked --sysvipc --link2symlink --kill-on-exit --rootfs=/data/data/com.termux/files/usr/var/lib/proot-distro/installed-rootfs/debian /usr/bin/env -i HOME=/root LANG=C.UTF-8 TERM=xterm /bin/su -l root -c '/bin/bash' '-c' ' set -x echo $$ > "/tmp/run-debian.sh.pid" hostUID="$(cat /data/data/com.termux/files/usr/etc/hostUID)" port=expr $hostUID + 2200## 2200: direct port range sshd -p $port >/dev/null 2>&1 & disown if [ -f /etc/rc.local ] ; then /etc/rc.local fi sleep 315576000 ## Rip van Winkle for 10 years, holding the door open '

[Grimler91]

Seems like PATH isn't set correctly in your environment. It is trying to use apt from termux instead of the one from debian.

Probably happens because you are ssh'ing into it instead of proot-distro login. Sourcing /etc/profile once inside probably helps, and otherwise ssh'ing into termux instead and proot-distro login to get into the distro.

[Steve-Newcomb]

Excellent hint; many thanks. Looks like my .bashrc is probably the culprit. I'll run it down and report.

[Steve-Newcomb]

I'm not having much luck with tracking down the problem, but I found a roadblock may or may not be related. Now, responding to your suggestions.

(1) Sourcing /etc/profile ( . /etc/profile) doesn't help.

(2) Except when I'm doing development at home, I can't ssh into a termux session because termux doesn't run proxytunnel. When the phone is in the wild, the only way I can hope to ssh into the phone depends on establishing a proxytunnel-enabled reverse ssh tunnel from within Debian, which in turn depends on a proot-distro session that was automatically already invoked via, e.g., termux-schedule-job.

(I use a very similar technique on many Linux computers and routers. Each of them automatically establishes a reverse tunnel with a server, so that by talking to that server, I can talk to the computer, or, in this case, to the phone. Proxytunnel is necessary to the usefulness of such reverse tunnels because some ISPs interfere with ssh tunnels in various ways. Proxytunnel is handy because it can make an ssh tunnel indistinguishable from an https session, and ISPs and mobile network operators generally don't interfere with https sessions.)

(3) Changing the setting of PATH doesn't help either. Indeed, when I have ssh'd into Debian, /system/bin isn't readable, nor is /data/data/com.termux/files/usr/var/lib/proot-distro/installed-rootfs/debian/system/ within which the apt binary presumably is, and where I assume various binaries that might be installed via apt would also live. Permission is always denied unless I interactively called proot-distro to establish the session I'm actually using while attempting to access /system/.

(4) Note: One of the key purposes of tunneling into phones is regular system maintenance, regardless of their current network connections. The debian system running on a telephone cannot be practicably maintained if its application binaries cannot be updated within a session that was logged into from a remote location. I can understand the value of enforcing a distinction between the host and guest systems (termux vs. Debian, in my case). Do I need a way around this enforcement?

[ghost]

In the line https://github.com/termux/proot-distro/blob/d008ceb9a83821fe5b660697619bdb3c393aaff5/proot-distro.sh#L385

The distribution's PATH is firstly specified before termux ones so it should use apt from debian otherwise if there's no such command then it will use termux's apt.

@Steve-Newcomb can you post a echo $PATH output?

also try running proot-distro in isolated mode --isolated and see if you're having same issue to further diagnose it

[Steve-Newcomb]

The distribution's PATH is firstly specified before termux ones so it should use apt from debian otherwise if there's no such command then it will use termux's apt.

Quite right, but PATH has no effect on the invocation of binaries that are invoked via an absolute path, such as /system/bin/apt. (Unless PATH works differently than it has worked for the last 50 years.) The problem is that /system/bin, although it appears earlier in PATH, is simply unreadable, so the shell proceeds onward, trying the succeeding directories in PATH, as usual. To satisfy any curiosity you may have, though, here is the PATH

I'll try your --isolated suggestion. (But it appears that for whomever accesses the guest system via ssh, the guest system is already isolated, so to speak, from its own binaries.)

[Grimler91]

Quite right, but PATH has no effect on the invocation of binaries that are invoked via an absolute path

Sure, but what do you mean exactly? Are you invoking apt with an absolute path? If yes which absolute path, and why not use apt from $PATH?

such as /system/bin/apt.

There is no apt in /system/bin so trying to run /system/bin/apt will certainly fail.

The problem is that /system/bin, although it appears earlier in PATH, is simply unreadable, so the shell proceeds onward, trying the succeeding directories in PATH, as usual.

Termux's binaries are in /data/data/com.termux/files/usr/bin. There should be no need to use any of android's tools in /system/bin/. You need to have /usr/bin/ (bound to the folder with debian's binaries) in PATH before /data/data/com.termux/files/usr/bin/ (aka $PREFIX/bin), it seems in your case that /usr/bin/ is either missing from PATH, or is later than $PREFIX/bin

To satisfy any curiosity you may have, though, here is the PATH

Seems that you forgot to paste your PATH

I'll try your --isolated suggestion. (But it appears that for whomever accesses the guest system via ssh, the guest system is already isolated, so to speak, from its own binaries.)

--isolated prevents debian proot from finding termux's binaries. Hopefully that makes it able to find its own binaries.

[Steve-Newcomb]

## First, on the phone's own termux window, I run "sshd -p 8023".
## N.B.: The phone's LAN ip is 192.168.4.35.

## Then, on a LAN host called "basil", I ssh into termux in the usual way:
220213 13:47 /persist/home/srn root@basil{1}# ssh -p 8023 192.168.4.35
X11 forwarding request failed on channel 0

## What Linux are we running?
220213 14:00 /root root@punch% uname -a
Linux localhost 5.4.0-faked #0 SMP PREEMPT Wed Nov 24 10:04:17 UTC 2021 aarch64 Android
220213 14:50 /root root@punch% 

## Yes, it's termux hosted by Android.  So far, so good.

## What's running?
220213 13:47 ~ u0_a279@punch% ps axw
  PID TTY      STAT   TIME COMMAND
 8366 pts/0    S<s+   0:00 /data/data/com.termux/files/usr/bin/bash -l
 8390 ?        S<     0:00 /data/data/com.termux/files/usr/bin/runsvdir /data/data/com.termux/files/usr/var/service
 9831 ?        S<s    0:00 sshd -p 8023
 9838 ?        S<s    0:00 /data/data/com.termux/files/usr/bin/sshd -p 8023 -R
 9839 pts/1    S<s    0:00 /data/data/com.termux/files/usr/bin/bash -l
 9923 pts/1    S<+    0:00 emacs
10564 ?        R<s    0:00 /data/data/com.termux/files/usr/bin/sshd -p 8023 -R
10570 pts/2    S<s    0:00 /data/data/com.termux/files/usr/bin/bash -l
11069 pts/2    R<+    0:00 ps axw
220213 13:48 ~ u0_a279@punch%

## In the above process list, note that the only sshd port is
## 8023.  Also note that proot is not running.

## What version of apt is termux's apt binary?
220213 13:48 ~ u0_a279@punch% apt --version
apt 2.3.15 (aarch64)
220213 13:52 ~ u0_a279@punch%

## Let's start an interactive prooted debian process:
220213 13:52 ~ u0_a279@punch% /data/data/com.termux/files/usr/bin/proot-distro login --fix-low-ports --termux-home --isolated --shared-tmp --bind /data/data/com.termux/files/usr/local/ch-tools3:/usr/local/ch-tools3 debian
root@localhost:~#

## OK, we're in Debian-land now, but just to be sure, are we running a
## faked Linux?
root@localhost:~# uname -a
Linux localhost 5.4.0-faked #0 SMP PREEMPT Wed Nov 24 10:04:17 UTC 2021 aarch64 GNU/Linux
root@localhost:~#

## Yes, we're sure enough in Debian-land.

## What version of the apt binary is Debian/proot?
root@localhost:~# apt --version
apt 2.2.4 (arm64)
root@localhost:~# 

## Great.  Everything looks OK.  Unsurprisingly, Debian's apt binary is
## not the same version as termux's apt binary.

## Exactly where, in Debian-land, is the apt binary?
root@localhost:~# which apt
/usr/bin/apt
root@localhost:~# 

## Now let's start sshd within the context of Debian, so that Debian
## can be logged into directly.  (Remember that logging into Debian
## directly is the only way to log in via a proxytunnel'ed reverse ssh
## tunnel.  The complexities of proxytunnel'ed reverse ssh tunnels
## are irrelevant to this narrative, so I'm being very simple here.
## I'm about to show that, for users logging into Debian via ssh
## directly, apt refuses to run.
root@localhost:~# sshd -p 2235
root@localhost:~# 
-------------------------------------------------------------------------

## Now, while we leave this Debian session running in one terminal, we
## will move to another terminal to log into Debian directly, using
## the sshd server we just started at port 2235.

-------------------------------------------------------------------------
## Ssh into Debian-land.
220213 13:59 /persist/home/srn root@basil{1}# ssh -p 2235 192.168.4.35
X11 forwarding request failed on channel 0

## What Linux are we running?
220213 13:59 /root root@punch% uname -a
Linux localhost 5.4.0-faked #0 SMP PREEMPT Wed Nov 24 10:04:17 UTC 2021 aarch64 Android
220213 13:59 /root root@punch% 

## Good.  We have successfully logged into prooted-Debian.  (Note the
## -faked Linux.)

## What's running?
220213 13:59 /root root@punch% ps axw | grep sshd
 9831 ?        S<s    0:00 sshd -p 8023
 9838 ?        S<s    0:00 /data/data/com.termux/files/usr/bin/sshd -p 8023 -R
10564 ?        S<s    0:00 /data/data/com.termux/files/usr/bin/sshd -p 8023 -R
12990 ?        S<s    0:00 sshd -p 2235
13031 ?        S<s    0:00 /data/data/com.termux/files/usr/bin/sshd -p 2235 -R
13112 pts/3    S<+    0:00 grep sshd
220213 14:00 /root root@punch% 

## This looks fine. (Sshd is running on 2 ports.  Port 8023 gives
## access to the termux session still running in the first terminal.
## Port 2235 gives access to the Debian session.

## Does apt work?
220213 14:00 /root root@punch% apt --version
Ability to run this command as root has been disabled permanently for safety purposes.
220213 14:00 /root root@punch% 

## As you can see, apt refuses to work, instead complaining that I'm
## root.  And yet, I don't think I've ever run apt *without* being
## root.

## So, maybe my PATH is messing things up.  Just in case that's what's
## happening, Let's bypass PATH and invoke the known-correct apt
## binary with an absolute path (we already demonstrated that
## /usr/bin/apt is the correct path in the other window).
220213 14:00 /root root@punch% ls /usr/bin/apt
/usr/bin/apt*
220213 14:00 /root root@punch% /usr/bin/apt
Ability to run this command as root has been disabled permanently for safety purposes.
220213 14:00 /root root@punch%

## Evidently, purely because we ssh'd into the Debian session, the
## *same* apt binary refuses to work.  Baffling, isn't it?

[Grimler91]

@Steve-Newcomb thanks for the detailed steps!

## First, on the phone's own termux window, I run "sshd -p 8023".
## N.B.: The phone's LAN ip is 192.168.4.35.

## Then, on a LAN host called "basil", I ssh into termux in the usual way:
220213 13:47 /persist/home/srn root@basil{1}# ssh -p 8023 192.168.4.35
X11 forwarding request failed on channel 0

## What Linux are we running?
220213 14:00 /root root@punch% uname -a
Linux localhost 5.4.0-faked #0 SMP PREEMPT Wed Nov 24 10:04:17 UTC 2021 aarch64 Android
220213 14:50 /root root@punch% 

## Yes, it's termux hosted by Android.  So far, so good.

5.4.0-faked means that you are inside the proot already, so ssh -p 8023 192.168.4.35 doesn't seem to bring you into termux (or maybe you have modified your bashrc to automatically login into your proot-distro or something?) Your current dir and PS1, /root root@punch%, also look like it is inside a proot-distro and not in termux.

## What's running?
220213 13:47 ~ u0_a279@punch% ps axw

Here it looks more like you are in termux

  PID TTY      STAT   TIME COMMAND
 8366 pts/0    S<s+   0:00 /data/data/com.termux/files/usr/bin/bash -l
 8390 ?        S<     0:00 /data/data/com.termux/files/usr/bin/runsvdir /data/data/com.termux/files/usr/var/service
 9831 ?        S<s    0:00 sshd -p 8023
 9838 ?        S<s    0:00 /data/data/com.termux/files/usr/bin/sshd -p 8023 -R
 9839 pts/1    S<s    0:00 /data/data/com.termux/files/usr/bin/bash -l
 9923 pts/1    S<+    0:00 emacs
10564 ?        R<s    0:00 /data/data/com.termux/files/usr/bin/sshd -p 8023 -R
10570 pts/2    S<s    0:00 /data/data/com.termux/files/usr/bin/bash -l
11069 pts/2    R<+    0:00 ps axw
220213 13:48 ~ u0_a279@punch%

## In the above process list, note that the only sshd port is
## 8023.  Also note that proot is not running.

## What version of apt is termux's apt binary?
220213 13:48 ~ u0_a279@punch% apt --version
apt 2.3.15 (aarch64)
220213 13:52 ~ u0_a279@punch%

## Let's start an interactive prooted debian process:
220213 13:52 ~ u0_a279@punch% /data/data/com.termux/files/usr/bin/proot-distro login --fix-low-ports --termux-home --isolated --shared-tmp --bind /data/data/com.termux/files/usr/local/ch-tools3:/usr/local/ch-tools3 debian
root@localhost:~#

## OK, we're in Debian-land now, but just to be sure, are we running a
## faked Linux?
root@localhost:~# uname -a
Linux localhost 5.4.0-faked #0 SMP PREEMPT Wed Nov 24 10:04:17 UTC 2021 aarch64 GNU/Linux
root@localhost:~#

## Yes, we're sure enough in Debian-land.

## What version of the apt binary is Debian/proot?
root@localhost:~# apt --version
apt 2.2.4 (arm64)
root@localhost:~# 

## Great.  Everything looks OK.  Unsurprisingly, Debian's apt binary is
## not the same version as termux's apt binary.

## Exactly where, in Debian-land, is the apt binary?
root@localhost:~# which apt
/usr/bin/apt
root@localhost:~# 

## Now let's start sshd within the context of Debian, so that Debian
## can be logged into directly.  (Remember that logging into Debian
## directly is the only way to log in via a proxytunnel'ed reverse ssh
## tunnel.  The complexities of proxytunnel'ed reverse ssh tunnels
## are irrelevant to this narrative, so I'm being very simple here.
## I'm about to show that, for users logging into Debian via ssh
## directly, apt refuses to run.
root@localhost:~# sshd -p 2235
root@localhost:~# 
-------------------------------------------------------------------------

## Now, while we leave this Debian session running in one terminal, we
## will move to another terminal to log into Debian directly, using
## the sshd server we just started at port 2235.

-------------------------------------------------------------------------
## Ssh into Debian-land.
220213 13:59 /persist/home/srn root@basil{1}# ssh -p 2235 192.168.4.35
X11 forwarding request failed on channel 0

## What Linux are we running?
220213 13:59 /root root@punch% uname -a
Linux localhost 5.4.0-faked #0 SMP PREEMPT Wed Nov 24 10:04:17 UTC 2021 aarch64 Android
220213 13:59 /root root@punch% 

## Good.  We have successfully logged into prooted-Debian.  (Note the
## -faked Linux.)

## What's running?
220213 13:59 /root root@punch% ps axw | grep sshd
 9831 ?        S<s    0:00 sshd -p 8023
 9838 ?        S<s    0:00 /data/data/com.termux/files/usr/bin/sshd -p 8023 -R
10564 ?        S<s    0:00 /data/data/com.termux/files/usr/bin/sshd -p 8023 -R
12990 ?        S<s    0:00 sshd -p 2235
13031 ?        S<s    0:00 /data/data/com.termux/files/usr/bin/sshd -p 2235 -R
13112 pts/3    S<+    0:00 grep sshd
220213 14:00 /root root@punch% 

## This looks fine. (Sshd is running on 2 ports.  Port 8023 gives
## access to the termux session still running in the first terminal.
## Port 2235 gives access to the Debian session.

Do you have openssh-server installed in debian or is it termux's sshd that is run? You have /data/data/com.termux/files/usr/bin/sshd -p 2235 -R in the list of running processes, which indicates that it is termux's sshd that is used. What does sshd --help from debian show?

## Does apt work?
220213 14:00 /root root@punch% apt --version
Ability to run this command as root has been disabled permanently for safety purposes.
220213 14:00 /root root@punch% 

## As you can see, apt refuses to work, instead complaining that I'm
## root.  And yet, I don't think I've ever run apt *without* being
## root.

## So, maybe my PATH is messing things up.  Just in case that's what's
## happening, Let's bypass PATH and invoke the known-correct apt
## binary with an absolute path (we already demonstrated that
## /usr/bin/apt is the correct path in the other window).

What does echo $PATH show when you proot-distro login debian vs when you ssh into debian?

220213 14:00 /root root@punch% ls /usr/bin/apt
/usr/bin/apt*
220213 14:00 /root root@punch% /usr/bin/apt
Ability to run this command as root has been disabled permanently for safety purposes.
220213 14:00 /root root@punch%

## Evidently, purely because we ssh'd into the Debian session, the
## *same* apt binary refuses to work.  Baffling, isn't it?

When you ssh into debian /data/data/com.termux/files/usr/bin seem to be bound to /usr/bin/, since /usr/bin/apt is termux's apt.

I don't how to fix this though, hopefully a proot-guru can help here.

[Steve-Newcomb]

Grimler91, thanks for your review and very helpful questions. You were right to complain about being confused by my PS1 prompt-string environment variable, which is set by my very own ~.bashrc. You were insightful to ask whether I had installed openssh-server in proot/Debian. I HADN'T DONE THAT, I guess because I assumed it was built in. It wasn't built in, but it's built into termux. Somehow, in a manner I don't yet understand, my .bashrc in the context of proot/Debian caused termux's sshd binary to be available within proot/Debian, where it sort-of worked. It did allow me to log in directly to proot/Debian, but, once I arrived there, apt didn't like me at all. Yikes, such confusion! The proot technology is important, necessary, and, alas, confusing, I think. My years of Linux system administration thinking-habits are tending to lead me to assume things that I shouldn't be assuming in the context of a prooted system. In an effort to make my presentation of the problem clearer, I did it all again with my .../home/.bashrc disabled. My .bashrc was presumably being executed separately at each login, both termux and proot, because the home directory is bound to both /data/data/com.termux/files/home in termux and to /root in the prooted Debian. Having disabled .bashrc (I renamed it to something harmless), I restarted the phone for a clean beginning.
Things went much differently this time. The main difference, for purposes of our discussion, was that I couldn't start sshd under proot/Debian. For the first time, I had to install openssh-server before there was an sshd to invoke. With sshd installed, apt works correctly for users logged in under it, even though the binary's address is still /usr/bin/apt. Wow. When/if I figure out exactly what the problem was with my .bashrc, I'll try to remember to report it here. So, I'm leaving this issue open for the nonce. Thanks for your help, Grimler91. As you certainly know, when other pairs of eyes look at a given problem, the original pair of eyes may experience a semi-magical enhancement of the insights available to them. Thanks for the brain-time!

[michalbednarski]

In transcript above (https://github.com/termux/proot-distro/issues/193#issuecomment-1038394361) you used proot-distro login --isolated and therefore you shouldn't be able to launch Termux's sshd there (please make sure that is the case, otherwise thats already a bug)

If you're not in --isolated mode then it sounds like termux-exec has redirected execution of program (termux-exec is LD_PRELOAD-based hook redirecting program execution to Termux's bin directory even if you pass absolute path, use echo $LD_PRELOAD to confirm its presence)

If you're in --isolated mode (make sure you don't have anything left running from previous attempts, use kill -9 -1 to terminate all Termux processes, after that launch new sshd instance) then this is likely proot bug, although on my device I couldn't reproduce using following script

Warning: test script below wipes proot-distro Debian installation, rename /data/data/com.termux/files/usr/var/lib/proot-distro/installed-rootfs/debian directory before running script if you want to keep it (and rename it back after testing)

#!/data/data/com.termux/files/usr/bin/bash
# https://github.com/termux/proot-distro/issues/193
set -xe
if ! [ -e ~/.ssh/id_rsa_testscript ]; then
        ssh-keygen -f ~/.ssh/id_rsa_testscript -N ''
fi 
proot-distro remove debian || true
proot-distro install debian
proot-distro login --isolated debian -- bash -c 'apt update && apt upgrade -y && apt install -y openssh-server'
mkdir -p ~/../usr/var/lib/proot-distro/installed-rootfs/debian/run/sshd
mkdir -p ~/../usr/var/lib/proot-distro/installed-rootfs/debian/root/.ssh
cat ~/.ssh/id_rsa_testscript.pub > ~/../usr/var/lib/proot-distro/installed-rootfs/debian/root/.ssh/authorized_keys
proot-distro login --isolated debian -- /usr/sbin/sshd -D -p 2236 &
sleep 2s
echo ================================================================================
ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -p 2236 -i ~/.ssh/id_rsa_testscript root@127.0.0.1 apt --version
echo ================================================================================
kill %1

[Steve-Newcomb]

First of all, I can find nothing suspicious or obnoxious in my .bashrc (although I found an unrelated, uh, infelicity).

Thanks, MichalBednarski, for the very interesting information. I bet the LD_PRELOAD business has something to do with my confusion regarding the running of apt under proot/Debian. But it probably doesn't explain why termux's sshd is being invoked in the absence of an installed openssh-server in proot/Debian. That is probably explained by the PATH I already have upon arrival in proot/Debian after a proot-distro install... invocation. Viz:

220214 13:29 ~ u0_a279@punch% /data/data/com.termux/files/usr/bin/proot-distro login --fix-low-ports --termux-home --shared-tmp --bind /data/data/com.termux/files/usr/local/ch-tools3:/usr/local/ch-tools3 debian
root@localhost:~# echo $PATH
/usr/local/ch-tools3:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/data/data/com.termux/files/usr/bin:/system/bin:/system/xbin
root@localhost:~# 

I don't think I put that /data/data/com.termux/files/usr/bin path in the PATH, but obviously it got there somehow. It's easy to surmise that, when I invoked sshd (sic) it wasn't found in /usr/sbin (openssh-server never having been installed), so the subsequent /data/data/com.termux/files/usr/bin path silently and ill-advisedly provided it.

I think my basic trouble was that, in the context of proot/Debian, I didn't install openssh-server before invoking sshd. The whole mess wouldn't have happened if I had done that first, I betcha. Lazy person that I am, however, I tend to try things before installing them, on the same theory that undergirds the practice of leaping-before-you-look as promoted in the documentation on exception handling in Python. Basically, it's better because it's cheaper to run.

But in this case, it wasn't cheaper. It would be interesting to know the theory, if any, behind the insertion of /data/data/com.termux/files/usr/bin in PATH. I'm sure there's an excellent reason for it, but I'm too new at proot to know what the reason is.

Thanks for your script, which worked. I'm attaching a run transcript FYI. I don't think it contains any surprises, though.

(Well, I tried to attach it, but this github discussion website says "We don't support that file type" and goes on to say I should try, among other things, TXT, which it already is (ZZ.TXT). Sigh. It's too big to reproduce here inline. I did try replacing 0x0a with 0x0d0x0a, in case it needs to look like a Windows .txt file. No help. Ain't life grand? Maybe it's just too big, and the unsupported-type message is misleading. So here's the end of it...)

Thanks, MichalBednarski, for the very interesting information.  I bet the LD_PRELOAD business has something to do with my confusion regarding the running of apt under proot/Debian.  But it probably doesn't explain why termux's sshd is being invoked in the absence of an installed openssh-server in proot/Debian.  That is probably explained by the PATH I already have upon arrival in proot/Debian after a `proot-distro install...` invocation.  Viz:

220214 13:29 ~ u0_a279@punch% /data/data/com.termux/files/usr/bin/proot-distro login --fix-low-ports --termux-home --shared-tmp --bind /data/data/com.termux/files/usr/local/ch-tools3:/usr/local/ch-tools3 debian root@localhost:~# echo $PATH /usr/local/ch-tools3:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/data/data/com.termux/files/usr/bin:/system/bin:/system/xbin root@localhost:~#

I don't think I put that `/data/data/com.termux/files/usr/bin` path in the PATH, but obviously it got there somehow.  It's easy to surmise that, when I invoked `sshd` (sic) it wasn't found in `/usr/sbin` (openssh-server never having been installed), so the subsequent `/data/data/com.termux/files/usr/bin` path silently and ill-advisedly provided it.  

I think my basic trouble was that, in the context of proot/Debian, I didn't install openssh-server before invoking sshd.  The whole mess wouldn't have happened if I had done that first, I betcha.  Lazy person that I am, however, I tend to try things before installing them, on the same theory that undergirds the practice of leaping-before-you-look as promoted in the documentation on exception handling in Python.  Basically, it's better because it's cheaper to run.

But in this case, it wasn't cheaper.  It would be interesting to know the theory, if any, behind the insertion of `/data/data/com.termux/files/usr/bin` in `PATH`.  I'm sure there's an excellent reason for it, but I'm too new at proot to know what the reason is.

Thanks for your script, which worked.  I'm attaching a run transcript FYI.  I don't think it contains any surprises, though.

(Well, I tried to attach it, but this github discussion website says "We don't support that file type" and goes on to say I should try, among other things, TXT, which it already is (ZZ.TXT).  Sigh.  It's too big to reproduce here inline.  I did try replacing linefeeds with carriagereturn-linefeeds in case it needs to look like a Windows .txt file.  No help.  Ain't life grand?  Maybe it's just too big, and the unsupported-type message is misleading.  So here's just the end of it...)

• sleep 2s
• proot-distro login --isolated debian -- /usr/sbin/sshd -D -p 2236

• echo ================================================================================

• ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -p 2236 -i /data/data/com.termux/files/home/.ssh/id_rsa_testscript root@127.0.0.1 apt --version Warning: Permanently added '[127.0.0.1]:2236' (ED25519) to the list of known hosts. apt 2.2.4 (arm64)

• echo ================================================================================

• kill %1

[vhscom]

Big thread. @Steve-Newcomb were you able to get the passthrough working? If so, would you mind sharing how you're using it as I think the following may be related: https://github.com/termux/proot-distro/issues/219

[Steve-Newcomb]

Big thread. @Steve-Newcomb were you able to get the passthrough working? If so, would you mind sharing how you're using it as I think the following may be related: #219

Yes, it works now. Sorry if that wasn't clear.

Re issue #219 I think all the OP needs to know is that the prooted ssh server can't be listening at port 8022, where Android's ssh server is listening, but rather at some other port. I think it's really as simple as that, and it has nothing to do with proxytunnel, which adds a load of complexity and normally involves at least one additional host.

[vhscom]

Thank you very much. 😊