[Eisfair] scp-Problem nach Base-Update auf 2.3.9

Olaf Jaehrling eisfair at ojaehrling.de
Mi Mär 4 08:45:37 CET 2015


Guten Morgen Marcus,

Am 04.03.2015 um 00:15 schrieb Marcus Roeckrath:

> 
> Aber auch hier steckt der Teufel im Detail.
> 
> Hat man zunächst die ssh-Konfiguration dazu benutzt, public-Keys für root
> festzulegen und löscht sie dann später wieder SSH_PUBLIC_KEYS_N=0, ist es
> logisch, dass die authorized_keys gelöscht wird.
> 
> In diesem Fall die authorized_keys unberührt zu lassen, würde die
> Konfiguration ad absurdum führen.

Da gebe ich dir natürlich vollkommen recht. Das ist immer so ein Kreuz, wenn sich sowas ändert. Bei BFB hatte ich das selbe Problem, wenn umgeschaltet wird von Remote-blocking auf local oder umgekehrt.

> 
> Ich sehe da nur einen Ausweg:
> 
> In /root/.ssh liegt eine "authorized_keys.add", die immer der
> authorized_keys hinzugefügt wird.

Das wäre ein guter Weg. Aber auch da stolpert man vermutlich. Angenommen in der authorized_keys.add steht der Key ssh-AAAfggg 
Nun rufe ich das setup 5 mal nacheinander auf. Dann steht dieser Key vermutlich 5 mal in der authorized_keys

Es blieben da nur 2 Wege. Entweder prüft die Installationsroutine jeden key einzeln, ob er in der authorized_keys steht oder es wird so ähnlich gemacht wie bei sudoers.
Wobei ich die sudoers-Variante bevorzugen würde.

Bedeutet also. Die authorized_keys wird immer gelehrt und dann werden alle keys aus (z.B.) authorized_keys.add, authorized_keys.privat, authorized_keys.wasweisich
der authorized_keys hinzugefügt. Somit könnte der Admin seine Keys, die er nicht übers setup konfigurieren will, in der authorized_keys.privat pflegen. Die keys im configfile werden der authorized_keys.add hinzugefügt und das modscht die setuproutine dann in authorized_keys zusammen. :)


Gruß

Olaf




Mehr Informationen über die Mailingliste Eisfair