Re: remote execution problem with ssh

From: Greg Wooledge (
Date: 03/02/05

  • Next message: Mark Leisher: "sftp - Received message too long 1265200236"
    Date: Wed, 2 Mar 2005 08:35:12 -0500
    To: Matthew Pratola <>

    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

    > 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

    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.

  • Next message: Mark Leisher: "sftp - Received message too long 1265200236"