Ok, so this is what I have done:
*-*-*-*-*-*-*-*-*-*-*
$idResults = `sudo -u admin ssh admin@xxxxxxxxxxx id usertocheck 2>&1`;
echo "id: (".$idResults.")\r\n"."\r\n";
if (ereg("no such user", $idResults)) {
echo 'id blah!';
}
*-*-*-*-*-*-*-*-*-*-*
And, here are the results that I get when I access the above code with my
browser:
*-*-*-*-*-*-*-*-*-*-*
id: (id: alain: no such user
)
id blah!
*-*-*-*-*-*-*-*-*-*-*
I have added the webserver user to sudoers which gives that user only the
ability to sudo to the admin user and run the ssh command which then allows
the webserver user to ssh to the remote machine without a password since I
setup secure keys for that user.
So what I wanted to do is now working. My question now would be, are there
any security concerns with how I am doing this? Aside from doing an id
check I will also be doing a remote command to add a user to the remote
system (ServerB) from the same PHP script. I will of course escapeshellarg
any information my users submit to the script.
Thanks,
Jonathan
"Richard Lynch" <ceo@xxxxxxxxx> wrote in message
news:1342.66.99.91.45.1102009659.squirrel@xxxxxxxxxxxxxxxx
> Gryffyn, Trevor wrote:
>> If it's a un*x system and you have permissions to connect to the SMTP
>> server, you could use the VRFY command to check to see if their email
>> address exists or not maybe:
>>
>> Example of Verifying a User Name
>>
>> Either
>>
>> S: VRFY Smith
>> R: 250 Fred Smith <Smith@xxxxxxxxxxxxx>
>>
>> Or
>>
>> S: VRFY Smith
>> R: 251 User not local; will forward to <Smith@xxxxxxxxxxxxx>
>>
>> Or
>>
>> S: VRFY Jones
>> R: 550 String does not match anything.
>>
>> Or
>>
>> S: VRFY Jones
>> R: 551 User not local; please try <Jones@xxxxxxxxxxxxx>
>>
>> Or
>>
>> S: VRFY Gourzenkyinplatz
>> R: 553 User ambiguous.
>>
>> (examples taken from: http://www.ietf.org/rfc/rfc0821.txt Page 8)
>
> I believe that, for performance and security reasons, many/most SMTP
> servers these days will out and out *LIE* to you about this...
>
> The real answer is: There is *NO* *WAY* to do this on a general basis,
> unless you control the remote machine, or know enough about its setup, to
> be certain that it will respond correctly.
>
>>> ServerA and ServerB
>
> Ah. The original poster probably has control of ServerB.
>
> Life is now simplified immensely.
>
>>> This, of course, is because the script is being run as "www"
>>> who has no
>>> place to put ssl keys.
>>>
>>> Could this be solved by having "www" "su" to a user who has
>>> remote access
>>> privileges? Something like this:
>>>
>>> $idResults = `su admin | ssh admin@xxxxxxxxxx id bigbob 2>&1`;
>
> su simply won't let you do that. su requires a TTY to avoid you doing
> something so incredibly dangerous as this.
>
> So, no, that won't work. And you shouldn't be trying to do that anyway.
>
>>> Anyone else doing or done something like this?
>
> Sure.
>
> I've never done it, but many many many have.
>
> One fairly simple thing is to create the 'www' user on ServerA so that
> they *do* have a home directory where they can store SSH keys. You may
> need to su to 'www' once, and do some ssh work -- ssh-key-gen or whatever
> it is.
>
> That, however, increases your risk in the event that the www user is
> compromised on ServerA.
>
> Probably the best answer is to attack this from the side of ServerB.
>
> You want ServerB to:
> Only allow ServerA to even ask.
> Tell ServerA if user "X" is a valid username.
>
> From the point of ServerB, making sure that ServerA is the one asking is
> fairly simple. You could check the IP (which can be spoofed, but that's
> fairly difficult) or provide some other means of authentication (SSH/SSL)
> that ensures that ServerA is really ServerA.
>
> Then, ServerB can just check /etc/passwd usernames. Or be even simpler to
> use a shell command like 'user' (?) or 'groups' to verify that a user is
> valid.
>
> In other words, instead of writing some hacky code on ServerA to try to
> poke at ServerB to get the answer you want, write some nice clean code on
> ServerB to provide the answer, WHEN APPROPRIATE.
>
> --
> 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
