1 |
On Mon, 15 Sep 2008, Michael Sullivan wrote: |
2 |
> On Mon, 2008-09-15 at 16:17 +0200, Alan McKinnon wrote: |
3 |
> > On Monday 15 September 2008 16:09:42 Michael Sullivan wrote: |
4 |
> > > Is there a way to do this? The problem with my |
5 |
> > > theories on how to do this fall apart when I get to the part where a |
6 |
> > > password has to be entered for rsync/scp. |
7 |
> > |
8 |
> > ssh keys. [...] |
9 |
> Create ssh keys without passphrases? That's not recommended... |
10 |
|
11 |
It depends: If you use these keys for nothing else than to login to |
12 |
your "server" machine (to fetch the portage tree) (and of course if |
13 |
you keep the key readable only for the cron-job on the client) then |
14 |
the only risk you have is: If the client (or the user for the cron-job) |
15 |
gets compromised then also the server might get compromised/spied to some |
16 |
extend (depending on which permissions allows the server to the account |
17 |
which you use for syncing, i.e. which is accepting the corresponding |
18 |
ssh key). |
19 |
|
20 |
But this risk is always there, no matter which approach you choose... |
21 |
|
22 |
An alternative - if you really just want to use keys with a passphrase - |
23 |
is to use net-misc/keychain. Of course, this means that you have to |
24 |
(manually) enter the passphrase at least once after booting or otherwise |
25 |
your cron-job will fail. |
26 |
|
27 |
> > and if you use eix to run update-eix afterward |
28 |
|
29 |
I would even recommend to use eix-sync to do all in the correct order: |
30 |
Call it on the client side with option "-s user@server[:dir]" |
31 |
(or put the line with this option into /etc/eix-sync.conf if you want |
32 |
to use this option practically always); this supports even keychain: |
33 |
Put e.g. the line |
34 |
~keychain --quiet ~/.ssh/id_rsa ; cat ~/.keychain/"$(hostname)-sh" |
35 |
into /etc/eix-sync.conf; see the eix manpage and eix-sync -h for details). |
36 |
|
37 |
An alternative might be to use option "-2 ..." on the server side, |
38 |
but this supports currently _one_ client and requires that eix-sync -u |
39 |
(or at least update-eix) is called afterwards on the client side. |