From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1P3vP9-00013V-Hm for garchives@archives.gentoo.org; Thu, 07 Oct 2010 18:41:23 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 716D4E07D8; Thu, 7 Oct 2010 18:40:33 +0000 (UTC) Received: from smtp206.alice.it (smtp206.alice.it [82.57.200.102]) by pigeon.gentoo.org (Postfix) with ESMTP id 2D4F8E07D8 for ; Thu, 7 Oct 2010 18:40:33 +0000 (UTC) Received: from infra.agr.fm (87.14.5.216) by smtp206.alice.it (8.5.124.08) id 4C1A268C0716D1B4 for gentoo-user@lists.gentoo.org; Thu, 7 Oct 2010 20:40:32 +0200 Received: from [192.168.64.9] (silver.agr.fm [192.168.64.9]) by infra.agr.fm (Postfix) with ESMTP id ECDD55DD11F for ; Thu, 7 Oct 2010 20:40:31 +0200 (CEST) Message-ID: <4CAE141F.7040904@alyf.net> Date: Thu, 07 Oct 2010 20:40:31 +0200 From: Andrea Conti User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Copying a file via ssh with no password, keeping the system safe References: <20101007184549.65756vlexbx2u7sw@momessonet.ath.cx> In-Reply-To: <20101007184549.65756vlexbx2u7sw@momessonet.ath.cx> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: cda2eaaf-4bf0-4e8f-a9eb-cc1dcd7748f8 X-Archives-Hash: 87129c685d40b7adbc1efbe02e1d2027 On 07/10/2010 18:45, Momesso Andrea wrote: > Setting up a public key, would do the job, but then, all the connection= s > between the servers would be passwordless, so if server A gets > compromised, also server B is screwed. Well, not really... public key authentication works on a per-user basis, so all you get is that some user with a specific key can log in as some other user of B without typing a password. Of course, if you authorize a given key for logging in as root@B, then what you said is true. But that is a problem with the specific setup. > Is there a way to allow only one single command from a single cronjob t= o > operate passwordless, while keeping all the other connections secured b= y > a password? You can't do that on a per-command basis. You'd be trying to control the authentication method accepted by sshd on B according to which command is run on A -- something sshd on B knows nothing about. I would try the following way: - Set up an unprivileged user on B -- let's call it foo -- which can only write to its own home directory, /home/foo. - add the public key you will be using (*) to foo@B's authorized_keys file. You should set the key's options to 'pattern=3D"",no-pty,command=3D"/usr/bin/scp -t -- /home/fo= o"' (man sshd for details). - chattr +i /home/foo/.ssh/authorized_keys, so that the file can only be changed by a superuser (you can't just chown the file to root as sshd is quite anal about the permissions of the authorized_keys file) Now your cron job on A can do "scp foo@B:/home/foo" without the need for entering a password; you just have to set up another cron job on B that picks up the file from /home/foo and puts it where it should go with the correct permissions, possibly after doing a sanity check on its contents. If you use something else than scp, (e.g. rsync) you should also adjust the command option in the key options above. Note that the option refers to what is run on B, not on A. Also, it is *not* an authorization directive =E0 la /etc/sudoers (i.e., it does not specify what commands the user is allowed to run): it simply overwrites whichever command is requested by the client side of the ssh connection, so that, for example, the client cannot request a shell or do "cat ". (*) You can either use the key of the user running the cron job on A, or generate a separate key which is only used for the copy operation. In this case, you will need to tell scp the location of the private key file with the -i option. HTH, andrea