Beschränken Sie den Zugriff auf ein privates Debian-Repository sicher

9

Ich suchte nach einer Methode, um den Zugriff auf ein privates Debian-Repository einzuschränken und mich nicht interaktiv bei ihm authentifizieren zu können (dh mithilfe eines Skripts).

Der nützlichste Artikel, den ich gefunden habe, ist tatsächlich einer von der Debian-Verwaltungssite, aber die sichere Methode verwendet ssh und öffentliche / private Schlüssel. Es funktioniert hervorragend, aber der öffentliche Schlüssel jedes Hosts muss sich in der Remote-Datei authorized_keys befinden, um sich erfolgreich zu authentifizieren. Es sagt nichts über die Bereitstellung eines Passworts für ssh: // aus, aber ich denke, es sollte möglich sein.

Haben Sie andere Alternativen ausprobiert (z. B. ftps)?

Danke im Voraus

— Humber
quelle

Das Problem, das ich mit dem obigen Artikel habe, ist, dass es nicht nur APT-Repository-Zugriff gewährt, sondern auch Shell-Zugriff auf meinen APT-Repository-Computer. Das ist ein inakzeptables Risiko.

— BobDoolittle

5

Wenn Sie apt-getIhre Server immer apt-getmanuell ausführen (keine automatischen Befehle, die von Cron gestartet werden), können Sie die Weiterleitung von SSH- Agenten in Betracht ziehen . Dadurch wird vermieden, dass pro verwaltetem Server ein öffentliches / privates Schlüsselpaar verwaltet werden muss, und es ist wahrscheinlich sicherer, als auf jedem Server private Schlüssel zu belassen.

Erstkonfiguration - Stellen Sie eine Verbindung zu den Servern her, die Sie verwalten möchten, und fügen Sie Folgendes hinzu /etc/apt/sources.list(in diesem Beispiel wird davon ausgegangen, dass Ihre Server eine Verbindung zum managerKonto herstellen sollen):

    deb ssh://manager@my.repository.org/path other stuff

Erstellen Sie ein Paar privater / öffentlicher Schlüssel auf Ihrem eigenen Computer, beispielsweise mit Ihrem Login johndoe(vorausgesetzt, Ihr Computer läuft unter Debian: Wenn nicht, können Sie dies von einem Debian-Server aus tun, der für die Verwaltung vorgesehen ist):
```
ssh-keygen
```
Stellen Sie sicher, dass es durch eine starke Schlüsselphrase geschützt ist
Kopieren Sie Ihren öffentlichen Schlüssel auf den Repository-Server in /home/manager/.ssh/authorized_keys:
```
ssh-copy-id manager@my.repository.org
```

Einmal pro Verwaltungssitzung

Starten Sie den SSH-Agenten auf Ihrem Computer, indem Sie Folgendes eingeben:
```
eval `ssh-agent`
```
Fügen Sie dem Agenten Ihren Schlüssel hinzu (dies erfordert Ihre Passphrase):
```
ssh-add
```

Server verwalten

Stellen Sie eine Verbindung zu dem Server her, den Sie verwalten möchten ssh -A( -Aaktiviert die Agentenweiterleitung):
```
ssh -A some.server.org
```
Wechseln Sie zu root (wenn Sie verwenden möchten, müssen sudoSie konfigurieren, /etc/sudoerssonst sudowird die Agentenweiterleitung unterbrochen, lesen Sie dies ):
```
su
```
Dank der Agentenweiterleitung sollten Sie nun in der Lage sein, mithilfe von ssh eine Verbindung zum Manager-Konto des Repositorys herzustellen, ohne Ihr Kennwort erneut eingeben zu müssen. Daher apt-getsollte gut funktionieren:
```
apt-get udate
```

Beenden Sie Ihre Verwaltungssitzung

Wenn Sie die Verwaltung Ihrer Server abgeschlossen haben, entfernen Sie Ihre Schlüssel vom Agenten:
```
ssh-add -D
```

Vorteile

Es ist nicht viel Erstkonfiguration erforderlich
Es ist nur ein privater Schlüssel erforderlich
Der private Schlüssel ist durch eine starke Passphrase geschützt
Wenn jemand Root-Zugriff auf einen Ihrer Server erhält, hat er keinen sofortigen Zugriff auf Ihren Repository-Server.
- Beachten Sie, dass der Hacker, wenn er geduldig und qualifiziert ist, warten kann, bis Sie mithilfe der Agentenweiterleitung eine Verbindung zum Server herstellen, und den Weiterleitungsmechanismus entführen kann, um Zugriff auf Ihren Repository-Server zu erhalten.
- Um dies zu verhindern, können Sie ssh-askjeden Versuch, Ihren Schlüssel zu verwenden, akzeptieren / ablehnen.
- In jedem Fall erhält der Hacker keinen Zugriff auf den privaten Schlüssel selbst: Er kann nur den Weiterleitungsmechanismus entführen, um den Schlüssel zu verwenden, und zwar nur während der Zeit, in der Sie mit dem Server verbunden sind.

— MiniQuark
quelle

Nochmals vielen Dank MiniQuark. Eigentlich sind die Updates unbeaufsichtigt, aber dies ist eine großartige Methode, die ich zu Testzwecken anwenden könnte.

— Humber

Gern geschehen! :) Schön, wenn es hilft.

— MiniQuark

4

Eine Möglichkeit, dies zu tun, besteht darin, bestimmten IP-Adressen den Zugriff auf das Repository zu ermöglichen. Dies funktioniert sehr gut für LAN und VPN.

Einfach und effizient.

— Antoine Benkemoun
quelle

1

Danke Antoine :). Tatsächlich ist das Repository, das ich jetzt habe, mit dieser Methode zugänglich (http über eine OpenVPN-Verbindung). Ich beschränke die IPs, die zum VPN gehören. Der Nachteil hierbei ist, dass jeder Host mit dem VPN verbunden sein muss, um auf das Repo zuzugreifen, was etwas ärgerlich ist (mehrere Zertifikate / Schlüssel verwalten). Entschuldigen Sie, dass Sie dies in der Frage nicht angegeben haben.

— Humber

Es ist zwar lästig, OpenVPN zu verwalten, aber es macht die Verwaltung der Sicherheit für Ihr Repository sehr einfach. Außerdem müssen sich Benutzer nicht einmal im VPN mit Anmeldeinformationen beschäftigen.

— Antoine Benkemoun

2

Die Lösung für öffentliche / private Schlüssel von ssh + ist gar nicht so schlecht:

Melden Sie sich als root auf dem Client-Computer an
Geben Sie ssh-keygendann einssh-copy-id your_login@your.repository.org

bearbeiten /etc/apt/sources.listund etwas hinzufügen wie:

deb ssh://your_login@your.repository.org/path other stuff

Zugegeben, Sie müssen den öffentlichen Schlüssel jedes Servers in die ~/.ssh/authorized_keysDatei auf dem Server einfügen, aber es ist nicht so kompliziert (siehe oben) und gibt Ihnen die Kontrolle darüber, welche Server Sie zu einem bestimmten Zeitpunkt zulassen oder nicht (Sie können einen Schlüssel unter entfernen) jederzeit in authorized_keys).

— MiniQuark
quelle

Danke MiniQuark. Ja, diese Lösung ist nicht so schlecht, aber ssh-copy-id funktioniert nicht, wenn die Kennwortauthentifizierung auf dem openssh-Server deaktiviert ist. Ich dachte daran, die gleiche Schlüsseldatei auf jedem Client unter Verwendung des Repositorys zu verbreiten, um sie verwenden zu können. Für mehr Sicherheit würde ein Benutzer mit minimalen Berechtigungen verwendet. Es ist fast das gleiche wie das Teilen von Anmeldeinformationen. Ich teste derzeit diese Methode, um zu überprüfen, wie sich das Verhalten verhält.

— Humber

1

Sie können einen https-Zugriff auf Ihr Repository einrichten, der durch Login / Passwort (Basisauthentifizierung) gesichert ist. Das Problem ist, dass Sie das Klartext-Login / Passwort eingeben müssen /etc/apt/sources.list(Hinweis: Es gibt einen Patch , mit dem das Login / Passwort /root/.netrcstattdessen eingegeben werden kann ).

— MiniQuark
quelle

Dies ist wahrscheinlich die beste Lösung, auch nicht netrc, sondern /etc/apt/auth.conf. Docs hier: manpages.debian.org/testing/apt/apt_auth.conf.5.en.html

— Nicholi

0

Der Link in Ihrer Frage zeigt mehrere Methoden. Sie möchten die Nummer 2, https + Basisauthentifizierung.

— Justin
quelle

Danke Justin. Ich denke, dass https Transport mit apt nur funktioniert, wenn apt-transport-https installiert ist. Dies ist eine interessante Alternative. Der einzige Nachteil ist die Anmeldeinformationen in sources.list

— Humber

chmod 600 /etc/apt/sources.list

— Justin