The value of $SSH_ORIGINAL_COMMAND (which is what is being logged here) reflects the fact that no command is present on the client's ssh command line. The script relies on the forced command (which is supposed to ignore the client command line otherwise and pass the value of $SSH_ORIGINAL_COMMAND on to the forced command script).
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
-----Original Message-----
From: Jochen Bern <Jochen.Bern@xxxxxxxxx>
Sent: Friday, June 30, 2023 1:12 AM
To: openssh-unix-dev@xxxxxxxxxxx
Cc: MCMANUS, MICHAEL P <mm1072@xxxxxxx>
Subject: Re: Subsystem sftp invoked even though forced command created
On 30.06.23 00:06, MCMANUS, MICHAEL P wrote:
> An authorized penetration tester brought to my attention that the private
> key embedded in the application can be extracted and used to launch a
> WinSCP session against the user ID which the client uses to send the data
> to the server.
As it happens, I have a system using dedicated keypairs and forced
commands configured for them to extract survey data from CentOS 7 boxes,
so let me try that ...
> $ ssh -t -q autoquest@bongo -p 29056 -i .ssh/id_uptime_ed25519
> 1688110066
> 1684949224
> 685215
> 0
> $ sftp -P 29056 -i .ssh/id_uptime_ed25519 -q autoquest@bongo
> Received message too long 825636920
Hm. Some specific quirk of WinSCP, maybe ... ?
[grabs Win10 box] [updates WinSCP to 6.1.1] [adds keypair to both ends]
... gets me an error (-> screenshot) suggesting that it received the
output from the forced command, and logs that the sshd has indeed run
the forced command. Sorry, cannot confirm so far ...
> I ran the client as is and received the following entry in the log:
> Command: 2>/dev/null
That's a weird, I'd even say nonfunctional, remote command, and makes me
suspect that your ssh command has a syntax problem ... ?
Kind regards,
--
Jochen Bern
Systemingenieur
Binect GmbH
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
