|
|
Posted by "Richard Lynch" on 08/18/05 09:30
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
> [www@svrA www]$ ssh www@svrB
>
> and I can also execute a shell script like
> [www@svrA www]$ ssh www@svrB /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 www@svrB /tmp/test.sh someDIR');
//Do this:
exec('ssh www@svrB /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 www@svrB /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:
www@svrA and www@svrB
From here on, I'll specify users with @svr? so we know what we're
talking about.
If the user 'nobody@svrA' is the one PHP runs as, then, yes,
'nobody@svrA' needs to have a copy of the [half-]key that currently is
owned by 'www@svrA' which is what allows 'www@svrA' to ssh to
'www@svrB' without supplying a password.
Though why you have a 'www@svrA' user and then have 'nobody@svrA'
running Apache/PHP is beyond my ken...
It's MORE likely that 'www@svrA' 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 'www@svrA' that you would
have sitting in the .ssh directory for 'www@svrA' and then the PUBLIC
half would be sitting in 'www@svrB' .ssh directory.
IE, the presence of the PUBLIC key belonging to somebody "else"
(www@svrA) in the file that, in theory, only 'www@svrB' can write, is
how www@svrB gave permission for www@svrA to get in.
www@svrB has the PUBLIC key to www@svrA, but that's okay. It's a
PUBLIC key, so anybody can safely hold it.
www@svrA 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:
www@svrB made a key-pair, and then handed over the PRIVATE key to
www@svrA
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
www@svrB) 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 www@svrA
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
Navigation:
[Reply to this message]
|