Why ssh ProxyJump and ProxyCommand options seem not working from a system account?
However, any time if I try to use from a system account, it fails. If I use it by su-ing into the system account, it works.
There is nothing relevant in the log. More clearly, the log states this for an ssh -v -v -v -J myjumphost mytarget output:
debug1: OpenSSH_10.0p2 Debian-7, OpenSSL 3.5.4 30 Sep 2025
debug3: Running on Linux 6.12.73+deb13-rt-amd64 #1 SMP PREEMPT_RT Debian 6.12.73-1 (2026-02-17) x86_64
debug3: Started with: ssh -v -v -v mytarget
debug1: Setting implicit ProxyCommand from ProxyJump: ssh -l jumphostuser -vvv -W '[%h]:%p' myjumphost
debug3: channel_clear_timeouts: clearing
debug1: Executing proxy command: exec ssh -l jumphostuser -vvv -W '[mytarget]:22' myjumphost
debug3: timeout: 10000 ms remain after connect
debug1: Local version string SSH-2.0-OpenSSH_10.0p2 Debian-7
kex_exchange_identification: Connection closed by remote host
Connection closed by UNKNOWN port 65535
1 answer
Most importantly, ProxyJump in SSH is only a wrapper to ProxyCommand. Essentially, ProxyJump does a port-forwarding-only SSH session to the jump host and then executes the SSH session over this forwarded port.
Its details are visible in the detailed log (-v -v -v).
The cause of the mysterious Connection closed by UNKNOWN port 65535 lies here: this error message is for port forwarding.
Thus in this case, the parent SSH process can only see a pipe with which it is communicating, not a socket. And a pipe does not have a port number.
After tracking down the problem, I have found sshconnect.c in the OpenSSH source code where the troubles start.
The cause of the problem is that the parent SSH process executes the forwarder to the ProxyJump in a shell. Always in a shell; there is no way to turn it off.
In my opinion, it is not clear why jumps must be done this way, but that's how they works, with no configuration settings to change it.
The shell being used depends on the SHELL environment variable. If there is no such environment variable, the SSH client will use a hardcoded default (most likely /usr/bin/sh).
However, system accounts like to have /usr/bin/false as their shells, resulting the same as the shell environment variable. Using false will exit with an error without doing anything, without reporting back anything, independently from its parameterization.
The very simple solution is: Although the system account might have /usr/bin/false as its shell variable, somehow set it up for the SSH client to use a valid shell.
The simplest way in a systemd-based system is to give an Environment=SHELL=/usr/bin/bash setting in the system service file.
0 comment threads
0 comment threads