Re: remote execution problem with ssh

• Previous message: Tay, Gary: "RE: OpenSSH_3.8.1p1 PermitRootLogin with bastille"
• In reply to: Matthew Pratola: "remote execution problem with ssh"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Date: Wed, 2 Mar 2005 08:35:12 -0500
To: Matthew Pratola <mtpratol@cs.sfu.ca>

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.

• Previous message: Tay, Gary: "RE: OpenSSH_3.8.1p1 PermitRootLogin with bastille"
• In reply to: Matthew Pratola: "remote execution problem with ssh"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]