Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
For me it’s also working if ~/.ssh/authorized_keys is owned by root, as long as the file is readable by the user.
What about using hostbased authentication for this particular machine? The authorized_keys file could be empty then and owned by root, to avoid that someone copies the user’s private key on the client machine to another one (in case the purpose is to avoid access from another machine from this user), or destroys the private key and look theirself out.
Thanks to everyone who has responded to this question!
The purpose here is indeed to avoid access from another machine from this user. It's an account out of which a public web site runs, and the user account needs to be accessed by staff for administration, which should only be done from a very restricted (kiosk-like) machine (where one cannot just copy the secret key and take it awsy) in a particular office. The website is run out of this account, which is implemented as a mix of C CGI and PHP using suPHP.
Shell access is necessary for some functions, so SSH must be enabled so I can get in and do what needs to be done. The concern is that if there is an exploit in any of the suPHP scripts that allowed someone to write files, someone could execute code as the user that could add to authorized keys. open_basedir is not a defense against a binary helper program, and binaries must be able to run in the web directory.
Last edited by chrys; 02-09-2012 at 01:19 AM.
Reason: Added to description of problem
The concern is that if there is an exploit in any of the suPHP scripts that allowed someone to write files, someone could execute code as the user that could add to authorized keys.
Erm.. if they can run code as the user, why wouldn't they just send an executing instance of /bin/sh back to themselves (and bypass most of the logging that sshd does)? Remember, if they're executing arbitrary code, you've lost.
Additionally, they'd be running as www-data/nobody/some other account, which is a completely separate user (unless you have your server running as root, and in that case you're boned).
I think you're making too niche of a security policy.