Restreindre en toute sécurité l'accès à un référentiel Debian privé

9

Je cherchais une méthode pour restreindre l'accès à un dépôt Debian privé et pouvoir m'authentifier de manière non interactive (c'est-à-dire en utilisant un script)

L'article le plus utile que j'ai trouvé est en fait celui du site d'administration Debian mais la méthode sécurisée utilise ssh et des clés publiques / privées. Cela fonctionne très bien, mais la clé publique de chaque hôte doit se trouver dans le fichier distant authorized_keys pour s'authentifier avec succès. Cela ne dit rien sur la fourniture de mot de passe à ssh: // mais je suppose que cela devrait être possible.

Avez-vous essayé d'autres alternatives (par exemple ftps)?

Merci d'avance

— Humber
source

Le problème que j'ai avec l'article ci-dessus est qu'il ne donne pas seulement un accès au référentiel APT - il donne un accès shell à ma machine de référentiel APT. C'est un risque inacceptable.

— BobDoolittle

5

Si vous exécutez toujours apt-getsur vos serveurs à la main (pas de apt-getcommandes automatiques lancées par crons), alors vous pourriez envisager d'utiliser le transfert d'agent ssh . Cela évite d'avoir à gérer une paire de clés publique / privée par serveur que vous gérez, et c'est probablement plus sûr que de laisser des clés privées sur chaque serveur.

Configuration initiale - connectez-vous aux serveurs que vous souhaitez gérer et ajoutez quelque chose comme ceci /etc/apt/sources.list(cet exemple suppose que vous souhaitez que vos serveurs se connectent au managercompte):

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

créer une paire de clés privées / publiques sur votre propre ordinateur, avec votre identifiant johndoepar exemple (à condition que votre ordinateur fonctionne sur Debian: sinon, vous pouvez le faire à partir d'un serveur Debian dédié à la gestion):
```
ssh-keygen
```
assurez-vous qu'il est protégé par une phrase clé forte
copiez votre clé publique sur le serveur de référentiel dans /home/manager/.ssh/authorized_keys:
```
ssh-copy-id manager@my.repository.org
```

Une fois par session de gestion

démarrez l'agent ssh sur votre machine en tapant:
```
eval `ssh-agent`
```
ajoutez votre clé à l'agent (cela nécessitera votre phrase secrète):
```
ssh-add
```

Gérer un serveur

se connecter au serveur que vous souhaitez gérer à l'aide ssh -A( -Aactive le transfert d'agent):
```
ssh -A some.server.org
```
passer à root (si vous voulez utiliser, sudovous devez configurer /etc/sudoersou sinon sudointerrompra le transfert d'agent, lisez ceci ):
```
su
```
vous devriez maintenant pouvoir vous connecter au compte du gestionnaire du référentiel en utilisant ssh sans taper à nouveau votre mot de passe, grâce au transfert d'agent. Par conséquent, apt-getdevrait fonctionner très bien:
```
apt-get udate
```

Fin de votre session de gestion

Une fois la gestion de vos serveurs terminée, supprimez vos clés de l'agent:
```
ssh-add -D
```

Les avantages

Pas beaucoup de configuration initiale est requise
Une seule clé privée est requise
La clé privée est protégée par une phrase secrète forte
Si quelqu'un obtient un accès root à l'un de vos serveurs, il n'aura pas immédiatement accès à votre serveur de référentiel.
- Notez que si le pirate est patient et qualifié, il peut attendre que vous vous connectiez au serveur en utilisant le transfert d'agent, et il peut détourner le mécanisme de transfert afin d'accéder à votre serveur de référentiel.
- Pour éviter cela, vous pouvez utiliser ssh-askafin d'accepter / refuser chaque tentative d'utilisation de votre clé.
- Dans tous les cas, le pirate n'aura pas accès à la clé privée elle-même: il pourra juste détourner le mécanisme de transfert pour utiliser la clé, et uniquement pendant la durée de connexion au serveur.

— MiniQuark
source

Merci encore MiniQuark. En fait, les mises à jour sont sans surveillance, mais c'est une excellente méthode que je pourrais appliquer à des fins de test.

— Humber

Mon plaisir! :) Content si ça aide.

— MiniQuark

4

Une façon de procéder consiste simplement à autoriser un certain ensemble d'adresses IP à accéder au référentiel. Cela fonctionne très bien pour le LAN et le VPN.

Simple et efficace.

— Antoine Benkemoun
source

1

Merci Antoine :). En fait, le référentiel que j'ai maintenant est accessible en utilisant cette méthode (http via une connexion OpenVPN). Je limite les adresses IP qui appartiennent au VPN. L'inconvénient ici est que chaque hôte doit être connecté au VPN pour accéder au référentiel, ce qui est un peu gênant (gérer plusieurs certificats / clés). Désolé de ne pas l'avoir précisé dans la question.

— Humber

Certes, il est gênant de gérer OpenVPN, mais cela rend la gestion de la sécurité de votre référentiel très simple. De plus, les utilisateurs n'ont pas à se soucier des informations d'identification une fois à l'intérieur du VPN.

— Antoine Benkemoun

2

La solution ssh + clés publiques / privées n'est pas si mauvaise:

se connecter en tant que root sur la machine cliente
tapez ssh-keygen, puisssh-copy-id your_login@your.repository.org

éditez /etc/apt/sources.listet ajoutez quelque chose comme:

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

Certes, cela vous oblige à mettre la clé publique de chaque serveur dans le ~/.ssh/authorized_keysfichier sur le serveur, mais ce n'est pas si compliqué (voir ci-dessus) et cela vous donne le contrôle sur les serveurs que vous autorisez ou non à un moment donné (vous pouvez supprimer une clé à à tout moment authorized_keys).

— MiniQuark
source

Merci MiniQuark. Oui, cette solution n'est pas si mauvaise, mais ssh-copy-id ne fonctionne pas si l'authentification par mot de passe est désactivée sur le serveur openssh. J'ai pensé à diffuser le même fichier clé sur chaque client en utilisant le référentiel pour pouvoir l'utiliser. Pour plus de sécurité, un utilisateur avec des autorisations minimales serait utilisé. C'est presque la même chose que le partage des informations d'identification. Je teste actuellement cette méthode pour vérifier comment se comporte / fonctionne.

— Humber

1

Vous pouvez configurer un accès https à votre référentiel, sécurisé par login / mot de passe (authentification de base). Le problème est que vous devez mettre le login / mot de passe en texte clair /etc/apt/sources.list(note: il y a un patch pour permettre à la place le login / mot de passe /root/.netrc).

— MiniQuark
source

C'est probablement la meilleure solution, ce n'est pas non plus netrc mais /etc/apt/auth.conf. Documents ici: manpages.debian.org/testing/apt/apt_auth.conf.5.fr.html

— Nicholi

0

Le lien dans votre question montre plusieurs méthodes. Vous voulez le numéro 2, https + authentification de base.

— Justin
source

Merci Justin. Je pense que le transport https avec apt ne fonctionne que si apt-transport-https est installé. Ceci est une alternative intéressante. Le seul inconvénient est les informations d'identification dans sources.list

— Humber

chmod 600 /etc/apt/sources.list

— Justin