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 1P3yqX-0002kA-6d for garchives@archives.gentoo.org; Thu, 07 Oct 2010 22:21:53 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 6A862E097A; Thu, 7 Oct 2010 22:21:22 +0000 (UTC) Received: from wlym.com (wlym.com [66.135.63.43]) by pigeon.gentoo.org (Postfix) with ESMTP id 30123E097A for ; Thu, 7 Oct 2010 22:21:21 +0000 (UTC) Received: from ccs.covici.com (pool-71-171-100-42.clppva.fios.verizon.net [71.171.100.42]) (authenticated bits=128) by wlym.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o97MLJqs008972 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 7 Oct 2010 17:21:21 -0500 Received: from ccs.covici.com (localhost [127.0.0.1]) by ccs.covici.com (8.14.4/8.14.4) with ESMTP id o97MLFlx005684 for ; Thu, 7 Oct 2010 18:21:18 -0400 To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Copying a file via ssh with no password, keeping the system safe In-reply-to: <20101007235946.82345qfl96r2s7i8@momessonet.ath.cx> References: <20101007184549.65756vlexbx2u7sw@momessonet.ath.cx> <4CAE141F.7040904@alyf.net> <20101007235946.82345qfl96r2s7i8@momessonet.ath.cx> Comments: In-reply-to Momesso Andrea message dated "Thu, 07 Oct 2010 23:59:46 +0200." X-Mailer: MH-E 8.2; nmh 1.3; GNU Emacs 23.2.1 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 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Thu, 07 Oct 2010 18:21:15 -0400 Message-ID: <5682.1286490075@ccs.covici.com> From: covici@ccs.covici.com X-Archives-Salt: d23900fc-0363-4144-aedd-c92610122a41 X-Archives-Hash: 20ab1a0a796e29a4e627085cefd55799 Momesso Andrea wrote: >=20 > Quoting Andrea Conti : >=20 > > On 07/10/2010 18:45, Momesso Andrea wrote: > > > >> Setting up a public key, would do the job, but then, all the connectio= ns > >> 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 = to > >> operate passwordless, while keeping all the other connections secured = by > >> 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/= foo"' > > (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 > > > > >=20 > Thank you all for your fast replies, I think I'll use all of your suggest= ions: >=20 > -create an unprivilegied user with no shell access as Stroller and > Andrea suggested >=20 > -I'll setup a passwordless key for this user, only limited to a single > command, as Willie > suggested >=20 > This sounds pretty sane to me. I think for ssh to work the user needs a valid shell, not nologin, so you can't do both of those suggestions.] --=20 Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici covici@ccs.covici.com