Subsystem sftp invoked even though forced command created

[MCMANUS, MICHAEL P]

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 at binect.de> 
Sent: Friday, June 30, 2023 1:12 AM
To: openssh-unix-dev at mindrot.org
Cc: MCMANUS, MICHAEL P <mm1072 at att.com>
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 at bongo -p 29056 -i .ssh/id_uptime_ed25519 
> 1688110066
> 1684949224
> 685215
> 0

> $ sftp -P 29056 -i .ssh/id_uptime_ed25519 -q autoquest at 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