openssh unix dev - Jul 2023 - Subsystem sftp invoked even though forced command created

On 30.06.23 17:56, MCMANUS, MICHAEL P wrote:
> The actual command is similar to the following (parameters inserted to
protect the source):
>          (print ${FQDN} ; print ${Environment} ; cat ${OutFileXML}) | \
>          ssh -Ti ${EmbeddedPrivateKey} \
>                  -o HostKeyAlias="${Alias}" \
>                  -o GlobalKnownHostsFile="${EmbeddedKnownHosts}" 
\
>                  -o
UserKnownHostsFile="${ClientSpecificKnownHosts}" \
>                  -o StrictHostKeyChecking="yes" \
>                  -o CheckHostIP="no" \
>                  -o NumberOfPasswordPrompts=0 \
>                  ${User}@${Host} 2>/dev/null
Then whatever executes this command line does *not* understand (and eat) 
the "2>/dev/null" like shells of the Bourne family should, hence it
winding up in the server-side $SSH_ORIGINAL_COMMAND ...
> debug1: server_input_channel_req: channel 0 request subsystem reply 1
> debug1: session_by_channel: session 0 channel 0
> debug1: session_input_channel_req: session 0 req subsystem
> debug2: subsystem request for sftp by user m61586
> debug1: subsystem: exec() /usr/libexec/openssh/sftp-server
> Starting session: forced-command (key-option)
'/opt/app/workload/secgov/opt/sact-central/bin/receive.ksh' for m61586
from 135.99.45.25 port 49734 id 0
Well, I'll be ... Looks like the server side recognizes the 
forced-command setup, but honors the SFTP subsystem request by exec()ing 
that nonetheless ... !

Kind regards,
-- 
Jochen Bern
Systemingenieur

Binect GmbH
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3449 bytes
Desc: S/MIME Cryptographic Signature
URL:
<http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20230703/4f77380a/attachment.p7s>

On Mon, 3 Jul 2023, Jochen Bern wrote:
> On 30.06.23 17:56, MCMANUS, MICHAEL P wrote:
> > The actual command is similar to the following (parameters inserted to
> > protect the source):
> >          (print ${FQDN} ; print ${Environment} ; cat ${OutFileXML}) |
\
> >          ssh -Ti ${EmbeddedPrivateKey} \
> >                  -o HostKeyAlias="${Alias}" \
> >                  -o
GlobalKnownHostsFile="${EmbeddedKnownHosts}"  \
> >                  -o
UserKnownHostsFile="${ClientSpecificKnownHosts}" \
> >                  -o StrictHostKeyChecking="yes" \
> >                  -o CheckHostIP="no" \
> >                  -o NumberOfPasswordPrompts=0 \
> >                  ${User}@${Host} 2>/dev/null
> 
> Then whatever executes this command line does *not* understand (and eat)
the
> "2>/dev/null" like shells of the Bourne family should, hence
it winding up in
> the server-side $SSH_ORIGINAL_COMMAND ...
> 
> > debug1: server_input_channel_req: channel 0 request subsystem reply 1
> > debug1: session_by_channel: session 0 channel 0
> > debug1: session_input_channel_req: session 0 req subsystem
> > debug2: subsystem request for sftp by user m61586
> > debug1: subsystem: exec() /usr/libexec/openssh/sftp-server
> > Starting session: forced-command (key-option)
> > '/opt/app/workload/secgov/opt/sact-central/bin/receive.ksh'
for m61586 from
> > 135.99.45.25 port 49734 id 0
> 
> Well, I'll be ... Looks like the server side recognizes the
forced-command
> setup, but honors the SFTP subsystem request by exec()ing that nonetheless
...
no, that's the log message being misleading. At the point of the
"Starting session: forced-command" in session.c:do_exec() the command
variable contains the requested forced command and that is what is
actually executed.

https://github.com/openssh/openssh-portable/blob/V_7_4_P1/session.c#L623-L663

The "subsystem: exec()" comes earlier from
session.c:session_subsystem_req(), which is recording (badly) which
subsystem was requested, but this is before the forced command is applied
in do_exec().

https://github.com/openssh/openssh-portable/blob/V_7_4_P1/session.c#L1938-L1944

Further evidence that this is the case is the audit calls that log the
command being executed:

debug3: mm_audit_run_command entering command
/opt/app/workload/secgov/opt/sact-central/bin/receive.ksh
debug3: mm_audit_end_command entering command
/opt/app/workload/secgov/opt/sact-central/bin/receive.ksh

So the command appears to have been correctly overridden and nothing in
the debug logs explains the behaviour you're reporting.

Some possibilities:

1. the receive.ksh script is faulty in some way that causes it to invoke
   sftp-server
2. some changes made by Redhat in the binaries they provided, not present
   in the OpenSSH source we release have broken forced commands.

#2 could be excluded by reproducing the problem using a sshd built from
source, without redhat's patches.

-d