From owner-freebsd-questions@FreeBSD.ORG Thu Nov 29 05:40:11 2007 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 55C4516A419 for ; Thu, 29 Nov 2007 05:40:11 +0000 (UTC) (envelope-from iaccounts@ibctech.ca) Received: from pearl.ibctech.ca (pearl.ibctech.ca [208.70.104.210]) by mx1.freebsd.org (Postfix) with ESMTP id 81A4313C447 for ; Thu, 29 Nov 2007 05:40:10 +0000 (UTC) (envelope-from iaccounts@ibctech.ca) Received: (qmail 90300 invoked by uid 1002); 29 Nov 2007 05:40:09 -0000 Received: from iaccounts@ibctech.ca by pearl.ibctech.ca by uid 89 with qmail-scanner-1.22 (spamassassin: 2.64. Clear:RC:1(208.70.104.100):. Processed in 12.58468 secs); 29 Nov 2007 05:40:09 -0000 Received: from unknown (HELO ?192.168.30.110?) (steve@ibctech.ca@208.70.104.100) by pearl.ibctech.ca with (DHE-RSA-AES256-SHA encrypted) SMTP; 29 Nov 2007 05:39:56 -0000 Message-ID: <474E50BC.7060501@ibctech.ca> Date: Thu, 29 Nov 2007 00:40:12 -0500 From: Steve Bertrand User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Kevin Downey References: <200711290428.lAT4SOLd065598@banyan.cs.ait.ac.th> <1d3ed48c0711282112g389407ddyed367561910adfe4@mail.gmail.com> In-Reply-To: <1d3ed48c0711282112g389407ddyed367561910adfe4@mail.gmail.com> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Olivier Nicole , freebsd-questions@freebsd.org Subject: Re: Secure remote shell X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2007 05:40:11 -0000 > ssh using key authentication and sudo configured to allow a certain > user to run the needed commands and only the needed commands as root. > http://www.gratisoft.us/sudo/ > http://sial.org/howto/openssh/publickey-auth/ Yes but in the OP's context, providing this would mean that ANY command supplied via the web interface would be allowed whether SSH or sudo was used to perform the remote execution via the web server. IMHO, there needs to be a distinctive separation as the 'support' persons request comes via the browser. If it is an 'adduser' type request, all aspects (mail, radius etc) need to have their own input-type authentication/authorization check on the input. Although sudo and SSH are part of the solution, providing a web server with full rights on a remote server if they can gain keyless entry is a large mistake. Tunnel via SSH, and escalate via sudo is both a good idea. But I think in the OP's context, there needs to be some intensive checks and bounds in between that make it *harder* for him to achieve his goals than what it could be. I don't think anyone would want the following scenario: - you pass https://url.com?blah&blahetc to webserver - webserver, via password-less ssh executes via sudo a command on remote RADIUS/mail to introduce a new user, perhaps in wheel group - owned Steve