For the benefit of others that may encounter this, the root cause of this problem was eventually identified. The problem was caused by the SSH-client-launched remote command running under a much older version of "bash", a version that had the (temporary) problem of not exporting the SSH_CLIENT variable to the environment.   How can this happen and be obscure? It turns out that when the CM executes "ssh 'bash -c ...'", the remote SSH server relies on a static search PATH to locate "bash", which may be different from the path you pick-up with interactive shells.   To check if you have this (unlikely) problem, run this from a machine remote from the target machine:   $ ssh you@yourmachine.com 'which bash' /usr/local/bin/bash $ ssh you@yourmachine.com 'bash --version' GNU bash, version 2.05.8(1)-release (i386-redhat-linux-gnu) $ ssh you@yourmachine.com 'env | grep SSH_CLIENT' SSH_CLIENT=10.1.2.3 56617 22 $ ssh you@yourmachine.com 'bash -c "env | grep SSH_CLIENT"' (nothing)   Note the really old version of bash reported here for me, and the non-standard path. Then when "bash" is explicitly invoked when checking SSH_CLIENT, it is missing. You can compare this to the results from an interactive shell session. The version of bash above and some other versions around the same time do not correctly export SSH_CLIENT.   The fix for this is eliminate the bad version of bash from the target machine.   Brett ... View more