On Wed, August 17, 2005 9:50 pm, Roger Thomas wrote:
> OK. I am able to setup remote key authentication between svrA and
> svrB. From svrA I can login to svrB with something like
> [EMAIL PROTECTED] www]$ ssh [EMAIL PROTECTED]
>
> and I can also execute a shell script like
> [EMAIL PROTECTED] www]$ ssh [EMAIL PROTECTED] /tmp/test.sh
Excellent!
If 'www' can do it in a shell, then PHP, running as 'www' can usually
do do it -- though a FEW commands require an honest-to-god tty
real-login-shell connection or they refuse to run. I think su is one
of them.
> On svrA I have a PHP script like so:
> <?
> system('ssh [EMAIL PROTECTED] /tmp/test.sh someDIR');
//Do this:
exec('ssh [EMAIL PROTECTED] /tmp/test.sh someDIR', $output, $error);
if ($error) echo "OS Error: $error\n";
echo implode("\n", $output);
This will tell you what error messages, if any, you are getting.
Most likely what is happening is that the 'www' user in PHP does not
have a true shell set up -- so 'www' has no "home" dir, so ssh does
not find the keys you stuck in ~/.ssh/ so you need to do something
like:
exec('ssh -i /home/www/.ssh [EMAIL PROTECTED] /tmp/test.sh someDIR', $output,
$error);
Read "man ssh" for more details about "-i" flag, but it basically
tells ssh where to find the keys it needs to use to get into svrB (and
anywhere else 'www' has access to)
I did the same thing with scp (kinda like FTP tunnelling through SSH)
and that was the thing that took me awhile to figure out.
> ?>
>
> /tmp/test.sh on svrB is only a one liner like so:
> mkdir /tmp/$1
>
> I ran the script from the browser but the /tmp/someDIR is not created
> :(
> Could it be that user nobody on svrA is *not* allowed to connect to
> svrB because the public key belongs to user www ? How do I rectify
> this ?
Whoa.
First of all, you have two different 'www' users running around:
[EMAIL PROTECTED] and [EMAIL PROTECTED]
>From here on, I'll specify users with @svr? so we know what we're
talking about.
If the user '[EMAIL PROTECTED]' is the one PHP runs as, then, yes,
'[EMAIL PROTECTED]' needs to have a copy of the [half-]key that currently is
owned by '[EMAIL PROTECTED]' which is what allows '[EMAIL PROTECTED]' to ssh to
'[EMAIL PROTECTED]' without supplying a password.
Though why you have a '[EMAIL PROTECTED]' user and then have '[EMAIL PROTECTED]'
running Apache/PHP is beyond my ken...
It's MORE likely that '[EMAIL PROTECTED]' really is running Apache/PHP, and you
are getting tripped up by what I outlined above.
BUT - yes, if the user running Apache/PHP doesn't have the half of the
key-pair that it needs to access srvB, then that user ain't getting
into svrB.
NOTE:
It's usually the PRIVATE key belonging to '[EMAIL PROTECTED]' that you would
have sitting in the .ssh directory for '[EMAIL PROTECTED]' and then the PUBLIC
half would be sitting in '[EMAIL PROTECTED]' .ssh directory.
IE, the presence of the PUBLIC key belonging to somebody "else"
([EMAIL PROTECTED]) in the file that, in theory, only '[EMAIL PROTECTED]' can
write, is
how [EMAIL PROTECTED] gave permission for [EMAIL PROTECTED] to get in.
[EMAIL PROTECTED] has the PUBLIC key to [EMAIL PROTECTED], but that's okay.
It's a
PUBLIC key, so anybody can safely hold it.
[EMAIL PROTECTED] has the PRIVATE key in his own .ssh directory, which only he
can access.
What you MAY have done, and which MIGHT work (or not) but seem
backwards to me:
[EMAIL PROTECTED] made a key-pair, and then handed over the PRIVATE key to
[EMAIL PROTECTED]
IF you did that, and IF that works, the risk here is that you've got a
key that is labeled as PRIVATE that has been handed "out" to somebody
else, which is a no-no.
And you've got a key that is labeled as PUBLIC (sitting up on
[EMAIL PROTECTED]) that you could easily someday think "Oh, it's okay to hand
this out, it's PUBLIC" but, really, *that* PUBLIC key is what is
supposed to be kept secret so that the PRIVATE key handed to [EMAIL PROTECTED]
can tie in...
> In the actual situation, I need to execute a shell script in svrB
> (from browser served by Apache on svrA) that only root can run. Please
> advise. I am getting very worried.
I'd be real worried about the script that only 'root' can run...
Set up a new user on svrB that has permission to create the
directories you need, and that's pretty much all that user can do.
Using 'root' access is just too much power.
Minimize your exposure ; Minimize your risk ; Minimize permissions
--
Like Music?
http://l-i-e.com/artists.htm
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
