On Tue, Mar 01, 2005 at 06:33:45PM -0800, Matthew Pratola wrote:
I have a peculiar problem i'm trying to track down. The issue is remote
execution using ssh. Passwordless logins are already setup and working
fine, the issue is with a command like the following:
/usr/bin/ssh -x DESTINATION_HOST -n COMMAND
will give the error COMMAND not found. However, excluding the -n, the
above will run fine.
I don't understand that one at all. -n only redirects standard input;
it shouldn't affect the execution of the commands on the remote system.
What's the actual "COMMAND" you're using? Does it have a fully qualified
pathname?
So it seemed that for some reason, the users
.profile was not being sourced
That's completely normal. You're launching a non-login shell on the remote
system, so it will never read /etc/profile or ~/.profile.
and so the PATH, etc variables were not
being setup correctly hence why it couldn't find COMMAND. So i created
the file /etc/ssh/sshrc that simply calls the users .profile file, but
this didn't change anything either.
From the sshd(8) man page:
8. If $HOME/.ssh/rc exists, runs it; else if /etc/ssh/sshrc
exists, runs it; otherwise runs xauth. The ``rc'' files are
given the X11 authentication protocol and cookie in standard
input.
So, at this point I must wonder whether you have a ~/.ssh/rc file which
is overriding /etc/ssh/sshrc. Also, I wonder what you actually *put*
into the sshrc file. What do you mean by "calls"? Did you execute
$HOME/.profile as a command, instead of dotting it in? That would most
certainly explain it, and I consider it the most likely explanation at
this point.
However, if i do something stupid,
like,
/usr/bin/ssh -x DESTINATION_HOST -n echo $PATH
then i can see that the path is indeed there.
No, this command causes the $PATH to be substituted on the client side,
by the shell, before /usr/bin/ssh is even executed. If you want the
*server* side to tell you the contents of the PATH variable, you need
to quote it properly, thus:
/usr/bin/ssh -x DESTINATION_HOST -n 'echo $PATH'
So it seems that straight
command execution when placed in the background with -n doesn't load up
all the users shell particulars, but otherwise things work the way they
should.
-n doesn't place the command into the background. It just redirects
standard input, and is required if you *do* place the command into the
background, for example with the shell's "&" operator. But since you
did not show an "&" in your command, there's no indication that you're
actually running anything in the background at all.
The documentation seems a little sparse in this regard (at least to me).
The man page is pretty clear to me. It's your question that lacks all
the necessary details. You didn't even say which versions of ssh you're
using on the client and the server.
