Interaction between sftp subsystem and forced command

Question

I'm responding to a penetration test finding on one of my application servers. The finding is that the private key embedded in my client script is capable of being used to open an SFTP session to the server.

My understanding has been that the use of the "command=" parameter on the relevant public key precludes the use of SFTP with the corresponding private key. However, the pen tester was able to use WinSCP with the key extracted from the client to access anything the service account owning the key can access.

The application uses the following command (suitably amended) to transfer data from client to server:

        (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

The forced command is set up in the public key with the "command=" parameter. I've inserted the following debug code at the top of the script executed by this parameter:

LOGFILE=/tmp/name-of-file.log
if [[ $SSH_ORIGINAL_COMMAND ]]; then
    print "Command: $SSH_ORIGINAL_COMMAND" >> $LOGFILE
else
    print "No SSH_ORIGINAL COMMAND set" >> $LOGFILE
fi

I then tried three things:

1. I ran the application as is.
2. I ran the application with a flag which removes the "2>/dev/null" after the ssh command for debugging purposes.
3. I attempted to log in to the same user ID with the same private key from a PC running WinSCP. This was successful, although to my understanding it should not have been.

After these steps, the logfile shows:

Command: 2>/dev/null
No SSH_ORIGINAL COMMAND set

There is no indication that the forced command even ran when I connected from WinSCP. So I'm unable to determine from there whether to accept the connection and attempt to read data from standard input.

I've read in several places that an SFTP connection is supposed to run the forced command before launching the sftp-server process, but this appears to not be the case, as whenever the WinSCP connection is active, the /usr/libexec/openssh/sftp-server process is running.

Is there a way to ensure a specific user/key cannot be used for interactive SFTP without breaking this method of file transfer?

Answer 1

If I understand your concerns correctly:

1. Make sure the user cannot use the private key to gain SSH access, which offers even more possibilities. The trick is usually to set the shell for the user to /bin/false. This is enough to create a SSH tunnel though and should be sufficient for SFTP afaik.
2. Limit what the user can do with that private key and reduce file exposure server-side. You're saying that the transfer is from client to server. Then you probably want a one-way communication channel, so that the client can upload new files, but cannot read remote files from the server. Then here is one relevant topic you may find useful How can I set up one-way scp?. One approach is to use ProFTPd, but OpenSSH should suffice as well. Disclaimer: I have not tried any of those suggestions but I intend to do so in the future.