Subsystem sftp invoked even though forced command created

[Jochen Bern]

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>