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
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
